Szolgáltatásmenedzsment Google-módra: Site Reliability Engineering

A rendszergazdai teendők egészen más szakismeretet igényelnek mint amivel a szoftverfejlesztők rendelkeznek, ezért a fejlesztők és a rendszergazdák külön-külön csoportokat képeznek. Ez a modell működőképes, azonban számos hátránnyal is bír, amelyek közvetlen és közvetett költségekként jelennek meg.

A szoftverfejlesztést merész analógiával a születéshez is hasonlíthatjuk: míg a szülés előtti rész és maga a szülés bonyolult és fájdalmas, a születés utáni időszakasz az, amelybe a legtöbb energiát fektetjük. Ezzel szemben a szoftvermérnökök a legtöbbet a szülés előtti és a szülés körüli részről beszélnek (maga a szoftver elkészítése és az élesítés folyamata). Ez ellentmondásban van azzal a gazdasági mutatóval, amely szerint egy szoftver termék összköltségének 40-90%-a az élesítés utáni szakaszban keletkezik.

Az az elképzelés, mely szerint az élesítésen “átesett” szoftver már stabil és nem igényel különösebb figyelmet, téves. Ehelyett a teljes szoftver életciklust érdemes végigkövetni, az ötlet megszületésétől annak dokumentációján és a kódíráson át az üzemeltetésig. Sőt, ezen túlmenően egészen a szoftver majdani törléséig.

Ez az a személet, amelyet a Site Reliability Engineer-ek magukénak vallanak.

“A remény nem stratégia” – tartja az SRE mondás

Kezdetben a cégek rendszergazdákat alkalmaztak bonyolult szoftver termékeik üzemeltetéséhez. A rendszergazda feladata volt, hogy a különböző szoftver komponenseket összeállítsa, éles környezetbe telepítse, majd frissítéseken keresztül nyomon kövesse annak életciklusát.  A rendszer növekedésével azonban egyre több rendszergazda alkalmazása vált szükségessé. Mivel a rendszergazdai teendők egészen más szakismeretet igényelnek mint amivel a szoftverfejlesztők rendelkeznek, ezért a fejlesztők (development, “dev”) és a rendszergazdák (operations, “ops”) külön-külön csoportokat képeznek.

Ez a modell egészen működőképes. Mindkét területen találunk szakembereket, a megszokott eszközökkel és módszertannal kezelhető a rendszer.

Azonban ez a megközelítés számos hátránnyal is bír, amelyek közvetlen és közvetett költségekként jelennek meg.

A közvetlen költségek egyértelműek: minden olyan szolgáltatás, amely manuális beavatkozásokat igényel egyre drágább lesz, ahogy a szolgáltatás egyre nő és egyre népszerűbbé válik.

A közvetett költségek már összetettebb problémát jelentenek: a fejlesztők és a rendszergazdák ellentétes érdekeket képviselnek.

A szoftverfejlesztők az új funkciókat és hibajavításokat a lehető minnél leghamarabb és nagy gyakorisággal szeretnék a felhasználókhoz eljuttatni. 

Ezzel szemben a rendszergazdák foggal-körömmel védik az éles környezetben működő rendszert, mert azt már stabilnak tekintik és nem szeretnék, hogy az új kiadás következtében a hibákkal – esetleges visszaállással – nekik kelljen bajlódniuk. Mivel minden szolgáltatáskiesést általában valamilyen változtatás előz meg (legyen az konfigurációs változtatás, vagy változás magában a kódban), így a két csoport között folyamatos feszültség áll fenn.

Mindkét csoport tisztában van vele, hogy nem vállalhatják fel a végletekig saját álláspontjukat, hiszen azzal az előrehaladást gátolják. Így eztán egyéni stratégiákat alakítanak ki: a rendszergazdák minden egyes élesítés előtt végigellenőrzik az összes lehetséges hibalehetőséget. Ez egy nagyon hosszú lista, amely nem garantálja teljes sikert. A fejlesztők is tudják, hogyan reagáljanak erre a problémára: kevesebb élesítést terveznek, ki-be kapcsolható funkciókat építenek a termékekbe, és válogatnak az élesítendő funkciók listájából. A a szoftvert kisebb egységekre osztják fel és ezeket egyenként élesítik.

Előző cikkünkben a Site Reliablity Engeneer szerepkörének kialakulását mutattuk be. Soron következő cikkünkben megnézzük, milyen megoldásokat alkalmaz a Google a fenti konfliktushelyzet megoldására.