Jaka jest różnica między SRE a DevOps?

Jaka jest różnica między SRE a DevOps?

Niezawodność witryny Operacje inżynieryjne i programistyczne wydają się nakładać na siebie bardzo szczegółowo. Skąd mam wiedzieć, która grupa jest odpowiedzialna za co i skąd mam wiedzieć, jakie stanowiska byłyby odpowiednie dla mojego zestawu umiejętności?

Wygląda na to, że SRE polega na utrzymywaniu serwerów i sieci, a DevOps na utrzymywaniu kodu, czy to prawda? Czy nadal nie ma dość pokrywania się tych dwóch elementów?

DevOps polega na utrzymywaniu kodu, czy to prawda?

DevOps to nie tylko „kod”, system, czy jakakolwiek inna rzecz. DevOps to bardzo ogólny termin, który obejmuje wszystkie rzeczy związane z dostarczaniem oprogramowania.

Inżynieria niezawodności witryny to termin spopularyzowany przez Google. Z tego artykułu https://landing.google.com/sre/interview/ben-treynor.html możemy destylować ich TL; DR:

Zasadniczo dzieje się tak, gdy poprosisz inżyniera oprogramowania o zaprojektowanie funkcji operacyjnej.

Rozmycie operacji, inżynierii i oprogramowania. Stopień automatyzacji wymagany do stworzenia i utrzymania dojrzałej infrastruktury wymaga umiejętności od wszystkich trzech. SRE są administratorzy, a inżynierowie i programiści.

Zobacz także: http://shop.oreilly.com/product/0636920041528.do

Dave Swersky opublikował już doskonałą odpowiedź powyżej z definicją SRE Bena Treynora, która jest równie wzruszająca dzisiaj, jak w 2003 roku.

Zasadniczo dzieje się tak, gdy poprosisz inżyniera oprogramowania o zaprojektowanie funkcji operacyjnej.

Tak więc, próbując dalej zdefiniować „DevOps”, oto fragment książki Effective DevOps Jennifer Davis i Katherine Daniels:

Devops to sposób myślenia i sposób działania. To ramy do dzielenia się historiami i rozwijania empatii ... [to] nie jest tylko kolejną metodologią tworzenia oprogramowania.

[P] taktyki mogą obejmować metody opracowywania oprogramowania lub funkcje, takie jak automatyzacja infrastruktury i ciągłe dostarczanie, [chociaż] to znacznie więcej niż tylko suma tych części.

Choć pojęcia te są ze sobą powiązane i często można je zobaczyć w środowiskach programistów, skupienie się wyłącznie na nich pomija szerszy obraz - aspekty kulturowe i interpersonalne, które dają programistom swoją moc.

Podsumowując: skuteczny SRE wykorzysta praktyki DevOps.

-

Również:

Skąd mam wiedzieć, która grupa jest odpowiedzialna za co?

Własność nie powinna być domniemana; komunikować się!

Inżynieria niezawodności witryny podlega mniej lub bardziej tradycyjnym operacjom, ale jest wysoce zautomatyzowana i kontrolowana pod względem wersji, co jest również nazywane infrastrukturą jako kod . Jest to dobrze określona rola pionowa . We współczesnych DevOps jest to pionowy wycinek, który odnosi się do operacji. Możesz mieć zespół SRE.

DevOps jako taka jest zmianą kulturową dla organizacji. Oprócz pionowej, z góry na dół struktury zarządzania, tworzy ona horyzontalne połączenie między zespołami wzdłuż ścieżek dostaw pracy w łańcuchach wartości . Dla inżyniera jest to luźno zdefiniowana pozioma rola , która łączy kilka zespołów razem, zapewniając, że praca przebiega płynnie i szybko w całej organizacji. Nie możesz mieć zespołu inżynierów DevOps, który jest oksymoronem , ponieważ przekroczenie granic zespołu jest kluczową częścią tej roli.

Innym sposobem na opisanie różnic między inżynierią niezawodności witryny a DevOps jest spojrzenie na wyjaśnienie Wikipedii dotyczące Site Reliability Engineer, które zaczyna się tak:

Inżynier niezawodności witryny (SRE) to opis zadania skierowany do inżynierów oprogramowania, koncentrujący się na niezawodności, skalowalności i rozwoju infrastruktury przetwarzania w chmurze, znanej jako inżynieria niezawodności witryny (SRE).

Więc możesz rozważyć SRE jako osoby zaangażowane w Building walls...

Jednak wyjaśnienie WikipediiDevOps zaczyna się tak:

DevOps ... to termin używany w odniesieniu do zestawu praktyk, które kładą nacisk na współpracę i komunikację zarówno twórców oprogramowania, jak i specjalistów technologii informatycznych (IT), jednocześnie automatyzując proces dostarczania oprogramowania i zmiany infrastruktury. Ma na celu stworzenie kultury i środowiska, w którym tworzenie, testowanie i wydawanie oprogramowania może się odbywać szybko, często i bardziej niezawodnie.

Nie mówi jednak, że wszystkie te praktyki DevOps są wywoływane przez popyt ze strony biznesu. Więc w połączeniu z tworzenia i testowania (The Develop część) oraz wersji oprogramowania, devops jest o DDR (= Zapotrzebowanie-Develop uwalnianiu) kultury i środowiska, które niektórzy mogą pamiętać z tych 9 sekund historycznego speach do Tear down this wall.

Zapoznaj się z pytaniem dotyczącym krótkiej przerwy planowanej na środę, 3 maja 2017 r. O godz. 20:00 czasu wschodniego / wschodniego (jak wiertarka ogniowa do komputerów), na przykład o wszystkich witrynach SE ... opublikowanych (podpisanych) przez użytkownika o nazwie SRE Manager , Stack Overflow, Inc.