Interní DevOps tým vs. externí konzultace: kdo má co vlastnit

Kdo se ve tři ráno probudí ke spadlé produkci? Ta jediná otázka rozhodne o vašem DevOpsu víc než celá debata, jestli stavět interní tým, nebo najmout externí konzultanty. Jakmile místo „kdo z nich“ začnete řešit „kdo co vlastní“, zjistíte, že nejlepší odpověď skoro vždy míchá obojí. Tenhle článek je o té hranici.

On-call a provoz patří dovnitř

Začněme tím, co se ven dávat nemá. Odpovědnost za běžící produkci, on-call rotu a reakci na incidenty držte interně. Technicky to externí tým zvládne. Jenže účet za výpadek platíte vy a člověk s vazbou na firmu se ve tři ráno probudí jinak než dodavatel s SLA „do rána“. Když on-call kompletně předáte ven, noční výpadek snadno čeká i půl hodiny, než se dodavatel probere. Interní senior s pagerem je u toho za pár minut.

Repozitář a znalost taky

Infrastruktura jako kód žije ve vašem Gitu, ve vaší organizaci. Interní tým má merge práva, externí přispívá přes pull requesty. Zní to jako detail, ale je to přesně ta hranice mezi partnerem a závislostí. Když architekt odejde, zůstane vám kód, historie i schopnost v něm dělat změny. Ne jenom kontakt na někoho, kdo tomu rozumí.

Co si půjčit zvenčí

Externí konzultace je nejsilnější tam, kde interní tým naráží na své limity.

Šířka zkušeností. Architekt, který viděl padesát podobných prostředí, vás provede rozhodnutím, které váš tým dělá poprvé.
Náběh. Nastaví CI/CD, IaC standardy a bezpečnostní review rychleji, než by je tým hledal sám.
Odstup. Řekne nahlas i to, co interně nikdo neřekne.
Kapacita ve špičkách. Utáhne tříměsíční projekt, aniž byste kvůli němu nabírali člověka na stálo.

Rozdělení odpovědností mezi interní tým a externí konzultaci. Interní tým vlastní provoz, on-call rotu, incidenty, deploymenty a merge práva k repozitáři. Externí konzultace vlastní architekturu, CI/CD a IaC standardy, bezpečnostní review, mentoring a kapacitu ve špičkách. Externí tým přispívá do vašeho repozitáře přes pull requesty. — Hranice vlastnictví: co drží interní tým a co externí partner.

Jak vypadá zdravé rozdělení

V praxi bývá kostra jednoduchá. Jeden až dva interní senioři drží provoz, on-call a každodenní vývoj infrastruktury. Externí architekt jezdí na pár dní v měsíci na těžká rozhodnutí, review a mentoring. Externí tým položí základ a odejde do role poradce ve chvíli, kdy ho interní lidi utáhnou sami.

Zdravý model spolupráce ve třech fázích: 1) externí tým položí základ (architektura, CI/CD, IaC standardy, školení týmu), 2) interní tým převezme provoz, on-call a každodenní vývoj, 3) externí architekt zůstává poradcem na pár dní v měsíci pro těžká rozhodnutí a review. — Externí tým základ postaví a předá, interní ho vlastní a provozuje.

Pokud interní tým zatím nemáte a provoz potřebujete hned, začněte opačně: plně spravovanou službou a znalost budujte postupně. O tom, kdy koupit DevOps jako službu, píšeme zvlášť.

Nakreslete si tu hranici dřív, než podepíšete jakoukoli smlouvu. Co musíte umět sami, drží tým s pagerem. Zbytek si přizvěte. A ten pager si nechte doma.

Časté dotazy

Interní DevOps tým, nebo externí konzultace?

Skoro vždy obojí. Provoz, on-call a odpovědnost za produkci držte interně. Architekturu, náběh nových praktik, bezpečnostní review a kapacitu ve špičkách si přizvěte zvenčí. Rozhodující není volba tábora, ale hranice, kdo co vlastní.

Co by měl vlastnit interní tým a co externí?

Interní tým: každodenní provoz, on-call rotu, incidenty, deploymenty a merge práva k infrastruktuře jako kódu. Externí konzultace: návrh architektury, nastavení CI/CD a IaC standardů, bezpečnostní review, mentoring a těžká rozhodnutí. Externí tým přispívá přes pull requesty, repozitář zůstává u vás.

Jak nevzniká závislost na externím dodavateli?

Infrastruktura jako kód žije ve vaší organizaci, interní tým má merge práva a externí přispívá přes pull requesty. Když partner odejde, zůstane vám kód, historie i schopnost ho měnit. Cílem dobré konzultace je tým vyškolit tak, aby vás jednou nepotřeboval.