Jaka jest różnica między tradycyjnym modelem rozwoju i operacyjnym a inżynierią niezawodności witryny?

15

„SRE dzieje się, gdy poprosisz inżyniera oprogramowania o zaprojektowanie zespołu operacyjnego”. - Inżynieria niezawodności witryny

Od wydania książki inżynierii niezawodności witryny Google więcej niż jeden raz powiedziano mi, że SRE jest rozszerzeniem istniejącego modelu obsługi lub wsparcia aplikacji.

Mieliśmy kilka pytań, które określały różnice między Sys. Administratorzy, inżynierowie DevOps i inżynierowie ds. Niezawodności witryny:

Żadne z tych pytań ani odpowiedzi nie opisują różnic między administratorem systemu a inżynierem niezawodności witryny .

Mówiąc szerzej: jakie są kluczowe różnice między praktyką Google w zakresie inżynierii niezawodności witryn a tradycyjnymi wydzielonymi funkcjami rozwoju i operacji w firmie.

Richard Slater
źródło

Odpowiedzi:

7

Na szczęście, ponieważ inżynieria niezawodności witryny została opracowana wewnętrznie w Google i dopiero niedawno zaczęła docierać do szerszej społeczności, jest dość dobrze zdefiniowana. To, czego nie ma , to operacje sieciowe (lub „administracja systemami” - jako przykład braku jasności używasz obu w pytaniu). Trudno dyskutować o różnicach między dwiema rzeczami, gdy nie jesteś całkowicie pewien, co to za jedna z nich.

Ale jestem żądnym przygód człowiekiem, więc dam temu szansę.


W bardzo tradycyjnych sklepach programiści i administratorzy są bardzo uciszeni. Deweloperzy tworzą aplikację, a następnie uznają, że ich praca jest ukończona, jak tylko kod zostanie zatwierdzony. Administratorzy systemu biorą artefakty kompilacji (które mogą być tylko kodem, jeśli jest to język interpretowany) i wdrażają go na serwerach produkcyjnych. Zadaniem sysadmins jest utrzymywanie płynności działania aplikacji i ogólne zarządzanie środowiskiem produkcyjnym. Jednak często problemy z wydajnością wynikają z problemów z architekturą w aplikacji; administratorzy nie mają wiedzy programistycznej, aby wiedzieć, co robi aplikacja, a programiści nie wiedzą, jak aplikacja działa w topologii produkcyjnej z ruchem produkcyjnym, więc nikt nie jest przygotowany do rozwiązania problemu.

Ponadto programiści są zwykle oceniani na podstawie tego, jak szybko mogą tworzyć nowe funkcje, podczas gdy sysadmini są oceniani na podstawie tego, jak rzadko aplikacja przerywa produkcję. Ponieważ zmiana jest jedną z głównych przyczyn zerwania, stawia to dwa działy w sprzeczności ze sobą - stara rywalizacja, która szkodzi biznesowi i zaangażowanym ludziom.

W pewnym momencie niektóre firmy zorientowane na deweloperów były tak zirytowane , że zaczęły ćwiczyć „NoOps” - wyeliminowały swoje działy operacyjne i domniemane przeszkody, które im towarzyszyły. W rzeczywistości oznaczało to, że programiści przyjęli role operacyjne, ale zachowali swoje stare tytuły.

W dyskusji wokół NoOps John Allspaw, następnie wiceprezes ds. Operacji technicznych w Etsy i redaktor szanowanej książki o operacjach sieciowych , zdefiniował role w Etsy w ten sposób:

Etsy Operations odpowiada za:

  • Reagowanie na awarie wymaga dyżuru
  • Progi systemów alarmowych, projektowanie
  • Projekt i przegląd architektury
  • Kolekcja metryk budowlanych
  • Konfiguracja aplikacji
  • Budowa / zarządzanie infrastrukturą

Etsy Development odpowiada za:

  • Reagowanie na awarie wymaga dyżuru
  • Progi systemów alarmowych, projektowanie
  • Projekt i przegląd architektury
  • Kolekcja metryk budowlanych
  • Konfiguracja aplikacji
  • Wysyłka publicznego kodu

Żadna z tych list nie jest wyczerpująca, jestem pewien, że coś tam brakuje. Chociaż Etsy Ops wprowadziło zmiany w aplikacjach, są one nieliczne, ale prawdziwe (a czasem dość głębokie). Podczas gdy Etsy Dev wprowadza zmiany szefa kuchni, jest ich niewiele, ale są prawdziwe. Jeśli obowiązki nakładają się na siebie tak wiele, dlaczego możesz o to zapytać? Specjalizacja w dziedzinie i pochodzenie. Niewielu deweloperów ma głęboką wiedzę o tym, jak działa powolny start TCP, ale działa Ops. Niewielu Operatorów ma wszechstronną wiedzę na temat algorytmów sortowania lub trafności, ale Dev ma. Ops ma wieloletnie doświadczenie w szybkim prognozowaniu zużycia zasobów z akceptowalną dokładnością, Dev nie. Deweloper może nie zdawać sobie sprawy z zalet i wad dystrybucji opcji obciążenia na wszystkich warstwach 1-7, a może tylko w wieku 7 lat. Modelowanie relacji między jednostkami może być naturalne dla programisty, ale nie dla operatorów. W końcu oboje odkrywają rozwiązania różnych form bizantyjskich scenariuszy awarii i wzorców odporności na wszystkich poziomach i warstwach.

W jego świecie programiści i inżynierowie operacyjni mieli bardzo podobne zestawy umiejętności i obowiązki na wysokim szczeblu; różniły się między sobą swoją wiedzą specjalistyczną. Różnorodne specjalizacje zachęcały ich do wspólnej pracy nad rozwiązywaniem problemów, a ich wspólne umiejętności na poziomie podstawowym dały im język, w którym można to zrobić.

Jest to ogólnie definicja operacji internetowych, na których bazuję w większości przypadków. Więc to ten, który będziemy kontynuować.


Czym więc jest inżynieria niezawodności witryny?

Książka Google SRE otwiera się definicją SRE ... a potem kolejną ... a następnie spędza rozdział na dalszym określaniu roli i całą książkę na ten temat. Nawet jeśli opracowano je w jednej organizacji, wydaje się, że trudno jest zawęzić pracę do jednej uzgodnionej definicji.

Na początek musimy wrócić do 2003 r., Kiedy Ben Traynor dołączył do Google i założył pierwszy zespół inżynierii niezawodności witryny. Przypomnijmy, że kilka akapitów temu byliśmy na początku 2010 roku; ale w 2003 r. branża wciąż była nastawiona na podział sysadmin / developer jako naturalny sposób działania. Kiedy więc Ben powiedział, że SRE miałoby miejsce, gdyby inżynier oprogramowania stworzył zespół operacyjny, było to znacznie bardziej radykalne połączenie tych dwóch światów, niż się obecnie wydaje.

Definicja podana we wstępie podkreśla każde z trzech słów osobno:

  • Inżynieria - wykorzystanie informatyki i inżynierii do rozwiązywania problemów
  • Niezawodność - nacisk na zwiększenie skalowalności, niezawodności i wydajności systemów
  • Usługa - późniejsza ewolucja „strony”, podkreślająca, że ​​SRE są odpowiedzialne za usługi sieciowe

Rozdział wprowadzający wymienia zasady inżynierii niezawodności witryny jako:

  • Zapewnienie trwałej koncentracji na inżynierii - podejmowanie działań zapobiegawczych w celu uniknięcia częstych stron i innych „prac”
  • Przekonanie o maksymalnej prędkości zmiany bez naruszania SLO usługi - temat, który może z łatwością uzyskać własną odpowiedź na kilkaset słów, ale z grubsza podsumowany jako pomoc programistom w dokonywaniu zmian, o ile nie powodują zbyt wielu problemów
  • Monitorowanie - automatyczne alerty, gdy coś pójdzie nie tak
  • Reakcja awaryjna - naprawianie rzeczy, gdy są zepsute
  • Zarządzanie zmianami
  • Planowanie wydajności
  • Provisioning
  • Wydajność i wydajność - zapewnienie, że usługa działa na oczekiwanym poziomie - wąskie gardło szkodzi użytkownikom, ale nadwyżka wydajności kosztuje

Sklasyfikowałbym Inżynieria niezawodności witryny jako wyspecjalizowany podzbiór nowoczesnych operacji sieciowych. Organizacja SRE koncentruje się w dużej mierze na automatyzacji wszystkiego , w stopniu, który jest opłacalny tylko w dość dużych firmach. Pomysły, takie jak budżety błędów, mogą działać tylko wtedy, gdy usługa ma wiele, wiele żądań, ponieważ w przeciwnym razie tracisz szczegółowość (w przypadku mniejszej usługi konkretny błąd może wpłynąć na 0-20% twoich żądań, w zależności od minuty). Powiązane obszary, takie jak bezpieczeństwo, są nieobecne w definicji SRE, ponieważ firmy wystarczająco duże, aby mieć prawdziwe zespoły SRE, mają dedykowane zespoły ds. Bezpieczeństwa.

Program SRE, zgodnie z definicją Google, to operacje internetowe opracowane z myślą o konkretnych potrzebach Google i niekoniecznie mają zastosowanie gdzie indziej.

Jednak Inżynieria niezawodności witryny rozwija się ostatnio w szerszym zastosowaniu w branży. Mój aktualny tytuł pracy to SRE, mimo że pracuję w znacznie mniejszej firmie, a mój opis stanowiska całkiem dobrze pasuje do definicji Johna Allspawa z 2012 Etsy. Moja teoria jest taka, że ​​robiliśmy postępy w tytułach, stając się skrótem dla ewolucji jednego pola:

  • Zaczęliśmy jako sysadmins .
  • Następnie, gdy strony internetowe stały się bardziej „rzeczą”, ogłoszenia o pracy zaczęły odnosić się do inżynierów operacji internetowych, aby odróżnić administratorów systemów, którzy specjalizowali się w sieci, od tych, którzy zajmowali się również IT w biurze ogólnym.
  • Następnie DevOps miał rozdzielić tych, którzy czuli się komfortowo, korzystając z programowania w celu zmniejszenia obciążenia swoich operacji internetowych.
  • Ponieważ jednak DevOps wpadł w zamieszanie z powodu braku jasnej definicji , przyjęliśmy Inżynierię niezawodności witryny, aby sprecyzować, że szukamy osób, które wspierają usługi produkcyjne na telefon.

Jaka jest więc różnica między sysadminem a SRE? Rok, w którym otrzymali tytuł. Jaka jest różnica między tradycyjnymi operacjami a inżynierią niezawodności witryny? SRE jest jedynie obecnym wcieleniem operacji, przy użyciu nowych narzędzi (cześć, kontenery!), A ponieważ programy sieciowe stają się coraz większe i ważniejsze, większy nacisk na praktyki, które pozwalają jednemu inżynierowi robić więcej .

Bojkot SE dla Moniki Cellio
źródło
Kilka interesujących lektur (z którymi niekoniecznie się zgadzam): charity.wtf/2016/06/30/… , charity.wtf/2016/05/31/wtf-is-operations-serverless , susanjfowler. com / blog / 2016/10/13 / the-ops-tożsamość-kryzys
Bojkot SE dla Moniki Cellio