Gdy osoby rozważają zaangażowanie w SRE i zespoły myślą o wprowadzeniu praktyk SRE, często pojawia się pytanie: "Czy musisz wiedzieć, jak kodować?"
Krótka odpowiedź: yeah.
Ale pełna odpowiedź jest nieco bardziej zniuansowana. Przyjrzyjmy się trzem miejscom, w których kodowanie wchodzi w grę w inżynierii niezawodności lokacji wraz z poziomem wiedzy dotyczącej kodowania wymaganej dla każdego z nich. Ta lista nie jest kompletna, ale te scenariusze są jednymi z bardziej typowych przypadków użycia.
Scenariusz 1. Usuwanie trudu za pośrednictwem automatyzacji
Inżynierowie niezawodności lokacji i inni, którzy używają praktyk inżynierii SRE, próbują wszędzie tam, gdzie to możliwe, aby usunąć trud. "Trud" oznacza konkretną rzecz w SRE. Trud odnosi się do pracy operacji wykonywanej przez człowieka, który ma pewne cechy. Trud nie ma długoterminowej wartości realizacji. Nie posuwa usługi do przodu w żaden znaczący sposób. Jest często powtarzalny i w dużej mierze ręczny (chociaż można go zautomatyzować). W miarę wzrostu usługi lub systemów w czasie prawdopodobnie proporcjonalnie wzrośnie liczba żądań dla danego systemu, co będzie przekładać się na jeszcze więcej zadań wykonywanych ręcznie.
Jeśli na przykład usługa wymaga, aby zespół SRE resetował coś co tydzień lub aprowizować nowe konta i miejsce na dysku ręcznie lub wielokrotnie ponownie uruchamiać go ręcznie — jest to obciążenie operacyjne, które jest trudem. Wykonanie tych czynności nie poprawi usługi w jakikolwiek długoterminowy, trwały sposób. Te czynności prawdopodobnie będą musiały być powtarzane wielokrotnie.
Inżynierowie ds. niezawodności witryny nienawidzą trudu. Pracują, aby go wyeliminować tam, gdzie jest to możliwe i stosowne. Jest to jedno z miejsc, w których do gry wkracza automatyzacja w SRE. Jeśli te żądania mogą być obsługiwane automatycznie, to zwalnia zespół do pracy nad bardziej satysfakcjonującymi i wpływającymi rzeczami.
Wiedza na temat kodowania: automatyzacja wymaga pewnej wiedzy w zakresie kodowania, ale nie musi wymagać pełnych umiejętności inżynieryjnych oprogramowania. Jeśli możesz pisać małe skrypty (na przykład w programie PowerShell lub powłoce Bourne), a nawet jeśli tworzysz aplikację logiki platformy Azure z ledwo dowolnym kodem, ta aplikacja nadal może pomóc wyeliminować trud.
Scenariusz 2. Kontrolowanie za pomocą interfejsów API/języków specyficznych dla domeny (DSLs)/templates
Chociaż nie jest to absolutnie konieczne do pracy w środowisku SRE, możliwość kontrolowania środowisk za pomocą interfejsów API, bibliotek DSL i szablonów (zwłaszcza środowisk w chmurze) umożliwia srEs skalowanie w górę pracy. Infrastruktura aprowizacji/anulowania aprowizacji, konfigurowanie monitorowania i integrowanie kilku usług staje się znacznie bardziej wydajna dzięki kodowaniu.
Wiedza na temat kodowania: podobnie jak w poprzednim scenariuszu, wymaga to pewnej wiedzy w zakresie kodowania, ale nie musi wymagać pełnych umiejętności inżynieryjnych oprogramowania. Oprócz wymienionych wcześniej skryptów i aplikacji logiki szablony usługi Azure Resource Manager mogą być również używane z minimalnym środowiskiem kodowania.
Scenariusz 3. Naprawianie kodu
Inżynierowie niezawodności lokacji chcą poprawić niezawodność systemu. Ten cel czasami wymaga zagłębienia się w kod źródłowy systemu, określenia problemu i często współtworzenia poprawki z powrotem do bazy kodu. Chociaż poziom wyrafinowania tej pracy może się znacznie różnić w zależności od sytuacji, doświadczenie w zakresie kodowania jest określonym wymaganiem w tych przypadkach.
Doświadczenie w zakresie kodowania: w tym scenariuszu często wymagana jest pełna wiedza inżynieryjna oprogramowania.
Następne kroki
Chcesz dowiedzieć się więcej na temat inżynierii niezawodności lokacji i pracy z małą ilością kodu? Zapoznaj się z naszym centrum inżynierii niezawodności lokacji, dokumentacją produktu połączoną powyżej.