Smashing Podcast Episode 42 z Jeffem Smithem: Co to jest DevOps?

W tym odcinku mówimy o DevOps. Co to jest i czy jest to ciąg znaków, który należy dodać do łuku programistycznego? Drew McLellan rozmawia z ekspertem Jeffem Smithem, aby się dowiedzieć.

Pokaż notatki

• Jeff na Twitterze
• Książka Jeffa Operations Anti-Patterns, DevOps Solutions
• Osiągalne DevOps

Cotygodniowa aktualizacja

• Wypełnianie luki między projektantami a programistami, autor: Matthew Talebi
• Przydatne interfejsy API React do tworzenia elastycznych komponentów za pomocą TypeScript napisane przez Gaurav Khanna
• Inteligentne rozwiązania CSS dla typowych wyzwań związanych z interfejsem użytkownika napisane przez Cosimę Mielke
• Wskazówki i porady dotyczące oceny projektantów UX/UI napisane przez Nataliyę Sambir
• Rozwiązywanie problemów z CLS w witrynie e-commerce opartej na Next.js napisanej przez Arijita Mondal

Transkrypcja

Drew McLellan: Jest praktykiem DevOps, który koncentruje się na osiągalnych poziomach implementacji DevOps, niezależnie od tego, na jakim etapie jesteś. Jest dyrektorem ds. produkcji w cyfrowej platformie reklamowej Centro, a także jest mówcą publicznym, dzieląc się swoją wiedzą na temat DevOps z publicznością na całym świecie. Jest autorem książki Operations Anti-Patterns, DevOps Solutions for Manning Publishing, która pokazuje, jak wdrażać techniki DevOps w niedoskonałych środowiskach, w których pracuje większość programistów. Wiemy więc, że jest ekspertem w DevOps, ale czy znasz George'a? Clooney uważa go za najlepszego producenta samolotów papierowych pokolenia? Moi przyjaciele Smashing, witajcie Jeffa Smitha. Cześć Jeff. Jak się masz?

Jeff Smith: Rozwalam, Drew, jak się masz?

Drew: Jestem dobry. Dziękuję Ci. Dobrze to słyszeć. Chciałem więc dzisiaj porozmawiać z wami na temat DevOps, który jest jednym z waszych głównych obszarów kluczowych. Wielu naszych słuchaczy będzie zaangażowanych w tworzenie stron internetowych i aplikacji, ale być może mają tylko luźną wiedzę na temat tego, co dzieje się po stronie operacyjnej. Wiem, że ci z nas, którzy mogą pracować w większych firmach, będą mieli całe zespoły kolegów, którzy wykonują operacje. Jesteśmy po prostu wdzięczni, że cokolwiek robią, robią to dobrze. Ale coraz częściej słyszymy o DevOps i wydaje się, że jest to jedna z tych rzeczy, które jako programiści powinniśmy naprawdę zrozumieć. Więc Jeff, czym jest DevOps?

Jeff: Więc jeśli zapytasz 20 osób, czym jest DevOps, możesz otrzymać 20 różnych odpowiedzi. Więc przedstawię ci moje zdanie, w porządku, i wiedz, że jeśli jesteś na konferencji i wspomnisz o tym, możesz wdać się z kimś w bójkę na pięści. Ale dla mnie DevOps tak naprawdę dotyczy relacji między programistami i operatorami, ale tak naprawdę tej relacji między zespołami i tego, jak zabieramy się do strukturyzowania naszej pracy i, co ważniejsze, strukturyzowania naszych celów i zachęt, aby upewnić się, że są dostosowane, abyśmy dążyli do wspólnego celu. Wiele podstawowych pomysłów i koncepcji DevOps pochodzi ze starego świata, w którym deweloperzy i operatorzy zawsze byli wrogo nastawieni, gdzie istniał nieustanny konflikt. A kiedy o tym myślisz, to ze względu na sposób, w jaki te dwie drużyny są motywowane. Jeden zespół jest zachęcany do forsowania zmian. Inny zespół jest zachęcany do utrzymywania stabilności, co oznacza mniej zmian.

Jeff: Kiedy to robisz, tworzysz ten nieodłączny konflikt i wszystko się stamtąd wylewa. Tak więc DevOps polega tak naprawdę na dopasowaniu tych zespołów i celów, tak abyśmy pracowali nad wspólną strategią, ale także na przyjmowaniu praktyk z obu stron, tak aby deweloperzy lepiej rozumieli operacje, a ops lepiej rozumieli deweloperów, jako sposób na zdobywanie i dzielenie się empatii ze sobą, abyśmy rozumieli perspektywę, z której pochodzi druga osoba.

Jeff: Ale także po to, by usprawnić naszą pracę. Bo znowu, jeśli zrozumiem twoją perspektywę i wezmę ją pod uwagę w swojej pracy, będzie to dużo korzystniejsze dla każdego z nas. Jest wiele rzeczy, których operatorzy mogą się nauczyć od programistów w zakresie automatyzacji i tego, jak podchodzimy do rzeczy, aby można je było łatwo odtworzyć. Więc to jest to mieszanie i umiejętności. Teraz widzisz, że dotyczy to różnych kombinacji grup, więc słyszysz takie rzeczy jak DevSecOps, DevSecFinOps, DevSecFinHROps. Będzie po prostu rosło, rosło i rosło. Tak naprawdę jest to lekcja, którą możemy stłumić w całej organizacji.

Drew: Bierzemy więc niektóre z koncepcji, które rozumiemy jako programiści, i rozpowszechniamy nasze pomysły dalej w organizacji, jednocześnie ucząc się, co możemy z operacji, aby spróbować posunąć wszystkich do przodu.

Jeff: Absolutnie, tak. Innym aspektem operacji, o którym wspomniałeś trochę we wstępie, jest to, że uważamy, że jest to tylko dla tych większych organizacji z dedykowanymi zespołami operacyjnymi i tym podobne, ale jedną rzeczą do przemyślenia jest to, że operacje mają miejsce w twojej organizacji, niezależnie od rozmiaru. To tylko kwestia tego, czy to robisz, czy robi to oddzielny zespół, ale jakoś wdrażasz kod. W jakiś sposób masz gdzieś działający serwer. Tak więc operacje istnieją gdzieś w Twojej organizacji, niezależnie od wielkości. Pytanie brzmi, kto to robi? A jeśli jest to pojedyncza osoba lub jedna grupa, DevOps może być dla Ciebie jeszcze bardziej istotny, ponieważ musisz zrozumieć rodzaje rzeczy, które robią ops.

Drew: Jako profesjonalni programiści, jak myślisz, jak ważne jest dla nas dobre rozeznanie, czym jest DevOps i co to znaczy wdrożyć?

Jeff: Myślę, że to bardzo ważne, szczególnie w tej fazie podróży DevOps. A powodem, dla którego uważam, że jest to ważne, jest to, że myślę, że zawsze jesteśmy bardziej wydajni, kiedy rozumiemy, co robią nasi koledzy. Ale drugą rzeczą jest możliwość wzięcia pod uwagę kwestii operacyjnych podczas opracowywania projektu i wdrażania dowolnej technologii. Jedną z rzeczy, których nauczyłem się w swojej karierze, jest to, że chociaż myślałem, że programiści są mistrzami wszechświata i rozumieją wszystko, co ma związek z komputerami, okazuje się, że tak nie jest. Okazuje się, że jest wiele rzeczy, które zlecają operatorom w zakresie zrozumienia, a czasami skutkują konkretnymi wyborami projektowymi lub wyborami implementacyjnymi, które mogą nie być optymalne dla wdrożenia produkcyjnego.

Jeff: Mogą być w porządku w rozwoju i testowaniu i tym podobnych rzeczach, ale kiedy dojdziesz do produkcji, to trochę inna gra w piłkę. Więc nie mówię, że muszą posiadać cały zestaw wiedzy, ale przynajmniej muszą wiedzieć wystarczająco dużo, aby wiedzieć, czego nie wiedzą. Wiedzą więc, kiedy wcześnie zaangażować się w operacje, ponieważ jest to powszechny wzorzec, w którym rozwój dokonuje wyboru. Nie powiem nawet dokonać wyboru, ponieważ nie są nawet świadomi, że jest to wybór, ale dzieje się coś, co prowadzi do nieoptymalnej decyzji dotyczącej operacji, a rozwój był całkowicie nieświadomy. Więc po prostu mając trochę więcej wiedzy na temat operacji, nawet jeśli wystarczy to powiedzieć, może powinniśmy wprowadzić w to opera, aby poznać ich perspektywę, zanim pójdziemy dalej. To może oczywiście zaoszczędzić dużo czasu, energii i stabilności, ponieważ odnosi się to do wszelkich produktów, które wypuszczasz.

Drew: Widzę wiele podobieństw do sposobu, w jaki mówisz o związku między programistami a operatorami, tak jak mamy między projektowaniem a programowaniem, gdzie projektanci pracują nad tym, jak działa i wygląda interfejs, i dobrze rozumieją tego, w jaki sposób zostanie to zbudowane w roli programisty, a zaangażowanie programistów na konsultacje może naprawdę poprawić ogólne rozwiązanie tylko dzięki jasnej komunikacji i zrozumieniu tego, co robią inni. Wygląda na to, że jest to ta sama zasada, którą stosuje się w przypadku DevOps, co naprawdę dobrze jest usłyszeć.

Drew: Kiedy myślę o rzeczach, które słyszę o DevOps, słyszę takie terminy jak Kubernetes, Docker, Jenkins, CircleCI. O Kubernetes słyszę od lat. Nadal nie mam pojęcia, co to jest, ale z tego, co mówisz, wydaje się, że DevOps to nie tylko… Nie mówimy tu tylko o narzędziach, prawda? Ale więcej o procesach i sposobach komunikowania się w przepływach pracy, czy to prawda?

Jeff: Absolutnie. Tak więc moją mantrą przez ostatnie 20 lat były zawsze narzędzia do przetwarzania ludzi. Skłaniasz ludzi do kupowania wizji. Stamtąd definiujesz, jak będzie wyglądał twój proces, aby osiągnąć tę wizję. A potem wprowadzasz narzędzia, które będą modelować niezależnie od tego, jaki jest twój proces. Dlatego zawsze umieszczam narzędzia na końcu rozmowy DevOps, głównie dlatego, że jeśli nie masz takiego wpisowego, to nie ma to znaczenia. Mógłbym wymyślić największy w historii potok ciągłego wdrażania, ale jeśli ludzie nie są przekonani, że wysyłanie każdej zmiany bezpośrednio do produkcji nie ma znaczenia, prawda? Jakie jest dobre narzędzie? Tak więc te narzędzia są zdecydowanie częścią rozmowy, tylko dlatego, że są standardowym sposobem na osiągnięcie pewnych wspólnych celów, które zdefiniowaliśmy.

Jeff: Ale musisz się upewnić, że te cele, które są zdefiniowane, mają sens dla Twojej organizacji. Może ciągłe wdrażanie nie ma dla Ciebie sensu. Może nie chcesz wysyłać każdej zmiany zaraz po jej pojawieniu się. I jest wiele firm i organizacji oraz powodów, dla których nie chciałbyś tego robić. Może więc coś takiego jak ciągły potok wdrażania nie ma dla Ciebie sensu. Tak więc, chociaż narzędzia są ważne, ważniejsze jest skupienie się na tym, co przyniesie wartość Twojej organizacji, a następnie modelowanie i wdrażanie narzędzi niezbędnych do osiągnięcia tego celu.

Jeff: Ale nie wchodź do sieci i nie dowiaduj się, co robią wszyscy, i bądź jak, och, cóż, jeśli mamy robić DevOps, musimy przełączyć się na Docker i Kubernetes, ponieważ to jest łańcuch narzędzi. Nie, to nie to. Możesz nie potrzebować tych rzeczy. Nie każdy jest Google. Nie każdy jest Netflixem. Przestań czytać posty z Netflixa i Google. Proszę po prostu przestań je czytać. Bo to sprawia, że ​​ludzie są podekscytowani i myślą, że to jest to, co musimy zrobić. I to jest tak, że rozwiązują zupełnie inne problemy niż te, które masz.

Drew: Więc jeśli powiem, że zaczynam nowy projekt, może jestem startupem, tworząc oprogramowanie jako produkt usługowy. Mam trzech programistów, puste repozytorium Git i marzenia o IPO. Aby być w całości w podejściu DevOps do tworzenia tego produktu, jakie są nazwy bloków konstrukcyjnych, które powinienem mieć na miejscu, jeśli chodzi o ludzi i procesy, i od czego mam zacząć?

Jeff: Więc w twoim konkretnym przykładzie, pierwszym miejscem, od którego zacząłbym, jest skupienie się na większości z nich tak często, jak to możliwe i użycie czegoś takiego jak Heroku lub coś w tym celu. Ponieważ jesteś tak podekscytowany tymi wszystkimi rzeczami AWS, Dockera, a w rzeczywistości tak trudno jest po prostu zbudować udany produkt. Pomysł, że skupiasz się na części DevOps, jest taki, cóż, powiedziałbym, że zlecisz jak najwięcej tych rzeczy, dopóki nie stanie się to problemem. Ale jeśli jesteś w tym momencie, w którym mówisz dobrze, jesteśmy gotowi zabrać te rzeczy do domu i jesteśmy gotowi przenieść to na wyższy poziom. Powiedziałbym, że najpierw należy zacząć od tego, gdzie są twoje punkty bólu? jakie są rzeczy, które powodują problemy?

Jeff: Więc dla niektórych jest to tak proste, jak automatyczne testowanie. Pomysł, że hej, musimy uruchamiać testy za każdym razem, gdy ktoś robi zatwierdzenie, ponieważ czasami wysyłamy rzeczy, które zostały złapane przez testy jednostkowe, które już napisaliśmy. Więc może zaczniesz od ciągłej integracji. Może ukończenie twoich wdrożeń zajmuje wiele godzin i są bardzo ręczne, więc na tym się skupiasz i mówisz: „OK, jakiej automatyzacji potrzebujemy, aby móc zrobić to jednym kliknięciem? Ale nienawidzę przepisywać generała, od tego zaczynasz, tylko dlatego, że twoja szczególna sytuacja i konkretne punkty bólu będą się różnić. Chodzi o to, że jeśli jest to problem, powinien na ciebie krzyczeć. To powinno na ciebie krzyczeć.

Jeff: To powinna być jedna z tych rzeczy, w których ktoś mówi, och, co jest do bani w twojej organizacji? I powinno być jak, och, wiem dokładnie, co to jest. Więc kiedy podejdziesz do tego z tej perspektywy, myślę, że kolejne kroki stają się dla ciebie dość oczywiste, jeśli chodzi o to, co w przyborniku DevOps musisz rozpakować i rozpocząć pracę. A potem pojawiają się te minimalne, przyrostowe zmiany, które po prostu nadchodzą i zauważasz, że gdy otrzymujesz nowe możliwości, twój apetyt na rzeczy niespełniające standardów staje się bardzo mały. Więc wychodzisz z jak, o tak, rozmieszczenia trwają trzy godziny i to jest w porządku. Wkładasz w to trochę wysiłku i następną rzeczą, którą wiesz, za trzy tygodnie, jesteś jak człowieku, nie mogę uwierzyć, że wdrożenie nadal trwa 30 minut. Jak to skrócić z 30 minut? Twój apetyt staje się nienasycony na poprawę. Więc wszystko po prostu wylewa się stamtąd.

Drew: Czytałem twoją ostatnią książkę i to podkreśla to, co nazywasz czterema filarami DevOps. I żadne z nich nie jest narzędziami, jak wspomniano, ale istnieją cztery główne obszary zainteresowania, jeśli chcesz, DevOps. Zauważyłem, że pierwszym z nich jest kultura, byłem tym dość zaskoczony, po pierwsze dlatego, że spodziewałem się, że będziesz więcej mówić o narzędziach i teraz rozumiemy dlaczego, ale jeśli chodzi o kulturę, wydaje się to po prostu dziwne rzecz, którą trzeba mieć na początku. Jest podstawa podejścia technicznego. Jak kultura wpływa na sukces wdrożenia DevOps w organizacji?

Drew: … jak udane może być wdrożenie DevOps w organizacji.

Jeff: Kultura jest tak naprawdę podstawą wszystkiego, kiedy się nad tym zastanowić. I jest to ważne, ponieważ kultura, i wchodzimy w to nieco głębiej w książce, ale kultura naprawdę przygotowuje grunt pod normy w organizacji. Prawidłowy. Prawdopodobnie byłeś w firmie, w której jeśli przesłałeś PR bez automatycznych testów, to nic wielkiego. Ludzie to akceptują i idą dalej.

Jeff: Ale są też inne organizacje, w których jest to grzechem kardynalnym. Prawidłowy. Gdzie, jeśli to zrobiłeś, to jest jak: „Wow, jesteś szalony? Co ty robisz? Tutaj nie ma przypadków testowych. Prawidłowy. To jest kultura. To jest kultura, która wymusza na tej normie powiedzenie: „To po prostu nie jest to, co robimy”.

Jeff: Każdy może napisać dokument, który mówi, że będziemy mieć automatyczne przypadki testowe, ale kultura organizacji jest tym, co wymusza ten mechanizm wśród ludzi. To tylko jeden mały przykład, dlaczego kultura jest tak ważna. Jeśli masz organizację, w której kultura jest kulturą strachu, kulturą zemsty. To tak, jakbyś popełnił błąd, prawda, to świętokradztwo. Prawidłowy. To jest równoznaczne ze zdradą. Prawidłowy.

Jeff: Tworzysz zachowania w tej organizacji, które są niekorzystne dla wszystkiego, co może być ryzykowne lub potencjalnie zawieść. A to kończy się pozostawiając wiele okazji na stole. Natomiast jeśli tworzysz kulturę, która obejmuje uczenie się od porażki, obejmuje ideę bezpieczeństwa psychicznego, w której ludzie mogą eksperymentować. A jeśli się mylą, mogą wymyślić, jak bezpiecznie ponieść porażkę i spróbować ponownie. Otrzymujesz kulturę eksperymentowania. Otrzymujesz organizację, w której ludzie są otwarci na nowe pomysły.

Jeff: Myślę, że wszyscy byliśmy w tych firmach, w których mówi się: „Cóż, tak to się po prostu robi. I nikt tego nie zmienia”. Prawidłowy. Nie chcesz tego, ponieważ świat ciągle się zmienia. Dlatego stawiamy kulturę na pierwszym planie, ponieważ wiele zachowań w organizacji istnieje dzięki kulturze, która istnieje.

Jeff: Rzecz w tym, że aktorzy kulturalni mogą być na dobre lub na złe. Prawidłowy. Jak na ironię, i mówimy o tym w książce, to fakt, że zmiana kultury organizacyjnej nie wymaga tak wielu ludzi, jak myślisz. Prawidłowy. Ponieważ większość ludzi jest krytyków, a potem są zwolennicy, a potem są opiekunowie ogrodzenia, jeśli chodzi o jakąkolwiek zmianę. A większość ludzi to opiekunowie ogrodzenia. Prawidłowy. Wystarczy garstka zwolenników, aby naprawdę przeważyć szalę. Ale w tym samym sensie, tak naprawdę wystarczy garstka krytyków, aby przechylić szalę.

Jeff: To tak, że nie trzeba wiele, aby zmienić kulturę na lepsze. A jeśli włożysz w to tę energię, nawet nie będąc starszym liderem, możesz naprawdę wpłynąć na kulturę swojego zespołu, co z kolei wpłynie na kulturę twojego działu, a następnie na kulturę organizacji.

Jeff: Możesz dokonać tych zmian kulturowych jako indywidualny współtwórca, po prostu głośno opowiadając się za tymi pomysłami i zachowaniami i mówiąc: „To są korzyści, które z tego czerpiemy”. Dlatego uważam, że kultura musi być na pierwszym miejscu, ponieważ musisz przekonać wszystkich do tego pomysłu i muszą zrozumieć, że jako organizacja będzie to opłacalne i wspierać ją.

Drew: Tak. To musi być sposób na życie, jak sądzę.

Jeff: Dokładnie.

Drew: Tak. Jestem naprawdę zainteresowany automatyzacją, ponieważ w mojej karierze nigdy nie widziałem wprowadzenia automatyzacji, która nie przynosiłaby korzyści. Prawidłowy. To znaczy, pomijając może dziwną rzecz, w której coś jest zautomatyzowane i idzie nie tak. Ogólnie rzecz biorąc, kiedy poświęcasz czas, aby usiąść i zautomatyzować coś, co robiłeś ręcznie, zawsze oszczędzasz czas i przestrzeń nad głową, a to tylko ciężar z twoich ramion.

Drew: Stosując podejście DevOps, jakiego rodzaju rzeczy chciałbyś zautomatyzować w swoich przepływach pracy? A jakich korzyści spodziewałbyś się dzięki temu, że ręcznie wykonasz zadania?

Jeff: Jeśli chodzi o automatyzację, to bardzo rzadko zdarza się, żeby automatyzacja nie polepszyła życia. Prawidłowy. Problem, z jakim spotykają się ludzie, polega na znalezieniu czasu na zbudowanie tej automatyzacji. Prawidłowy. I zazwyczaj, w mojej obecnej pracy, dla nas jest to właściwie punkt prośby. Prawidłowy. Ponieważ w pewnym momencie musisz powiedzieć: „Przestanę robić to ręcznie i zamierzam to zautomatyzować”.

Jeff: I może to być czas, kiedy otrzymujesz prośbę, w której mówisz: „Wiesz co? Zajmie to dwa tygodnie. Wiem, że zwykle odwracamy to w ciągu kilku godzin, ale zajmie to dwa tygodnie, ponieważ jest to żądanie, które jest zautomatyzowane”. W zakresie identyfikacji tego, co automatyzujesz. W Central korzystam z procesu, w którym w zasadzie próbkuję wszystkie różne typy żądań, które napływały w okresie, powiedzmy, czterech tygodni. I kategoryzowałbym je jako praca planowana, praca nieplanowana, praca z wartością dodaną, praca trudna. Trud w postaci pracy, która nie jest zbyt użyteczna, ale z jakiegoś powodu moja organizacja musi to robić.

Jeff: A potem identyfikujemy te rzeczy, które brzmią: „Ok, jaki jest nisko wiszący owoc, którego możemy się po prostu pozbyć, gdybyśmy to zautomatyzowali? Co możemy zrobić, aby to uprościć?” A jednym z kryteriów było ryzyko procesu. Prawidłowy. Zautomatyzowane przełączanie awaryjne bazy danych jest trochę przerażające, ponieważ nie wykonuje się ich tak często. I zmiany w infrastrukturze. Prawidłowy. Mówimy: „Jak często to robimy?” Jeśli robimy to raz w roku, automatyzacja może nie być warta, ponieważ jest to bardzo mało wartościowe. Ale jeśli to jedna z tych rzeczy, które dostajemy dwa, trzy razy w miesiącu, okej, spójrzmy na to. W porządku.

Jeff: Teraz, jakie są rzeczy, które możemy zrobić, aby to przyspieszyć? Chodzi o to, że kiedy mówimy o automatyzacji, od razu przeskakujemy do: „Nacisnę przycisk i to zostanie po prostu magicznie zrobione”. Prawidłowy. Ale jest tak wiele różnych kroków, które możesz wykonać w automatyzacji, jeśli masz mdłości. Prawidłowy. Załóżmy na przykład, że masz 10 kroków z 10 różnymi poleceniami CLI, które normalnie uruchamiasz. Twój pierwszy krok automatyzacji może być tak prosty, jak uruchomienie tego polecenia lub przynajmniej wyświetlenie tego polecenia. Prawidłowy. Powiedz: „Hej, to właśnie zamierzam wykonać. Myślisz, że to w porządku? "TAk." "Dobra. To jest wynik, który otrzymałem. Czy mogę kontynuować?” "TAk." "Dobra. To jest wynik, który uzyskałem.” Prawidłowy.

Jeff: W ten sposób nadal masz trochę kontroli. Czujesz się komfortowo. A potem po 20 egzekucjach zdajesz sobie sprawę, że tylko bijesz, tak, tak, tak, tak, tak, tak. Mówisz: „W porządku. Połączmy wszystkie te rzeczy razem i po prostu zróbmy to wszystko w jedno.” To nie tak, że musisz wskoczyć na głęboką wodę, kliknąć i zapomnieć o tym od razu. Możesz w to wejść, aż poczujesz się komfortowo.

Jeff: To są rodzaje rzeczy, które robiliśmy w ramach naszych wysiłków na rzecz automatyzacji, to po prostu, jak możemy przyspieszyć czas realizacji tego i zmniejszyć poziom wysiłku z naszej strony? Może nie jest to 100% pierwszego dnia, ale celem jest zawsze osiągnięcie 100%. Zaczniemy od małych fragmentów, z których zautomatyzujemy części, z którymi czujemy się komfortowo. TAk. Jesteśmy bardzo pewni, że to zadziała. W tej części jesteśmy trochę niepewni, więc może po prostu dostaniemy ludzką weryfikację, zanim przejdziemy dalej.

Jeff: Kolejna rzecz, na którą spojrzeliśmy w kontekście mówienia o automatyzacji, ale jaką wartość dodajemy do konkretnego procesu? A to jest szczególnie istotne w przypadku operatorów. Ponieważ często ops służy jako pośrednik w procesie. Wtedy ich zaangażowanie to nic innego jak jakiś dostęp. Prawidłowy. To tak, że ops musi to zrobić, ponieważ ops jest jedyną osobą, która ma dostęp.

Jeff: Cóż, to jest jak, no cóż, jak zlecić ten dostęp, aby ludzie mogli to zrobić? Ponieważ rzeczywistość jest taka, że ​​nie martwimy się, że deweloperzy mają dostęp do produkcji. Prawidłowy. Martwimy się, że programiści mają nieograniczony dostęp do produkcji. A to naprawdę kwestia bezpieczeństwa. Prawidłowy. To tak, jakby moja skrzynka z narzędziami miała tylko ostre noże, będę bardzo ostrożna, komu to rozdam. Ale jeśli potrafię pomieszać skrzynkę z narzędziami z łyżką i młotkiem, aby ludzie mogli wybrać odpowiednie narzędzie do pracy, o wiele łatwiej byłoby to wypożyczyć.

Jeff: Na przykład mieliśmy proces, w którym ludzie musieli uruchamiać ad hoc skrypty Ruby w produkcji, z jakiegokolwiek powodu. Prawidłowy. Trzeba wyczyścić dane, poprawić jakiś zły zapis, cokolwiek. I to zawsze przychodziło przez mój zespół. I to jest tak, że nie dodajemy do tego żadnej wartości, ponieważ nie mogę zatwierdzić tego biletu. Prawidłowy. Nie mam pojęcia. Napisałeś oprogramowanie, więc co mi z tego, że siedzę ci przez ramię i mówię „No cóż, myślę, że to bezpieczne”? Prawidłowy. Nie dodałem żadnej wartości do wpisywania, ponieważ po prostu wpisuję dokładnie to, co kazałeś mi wpisać. Prawidłowy.

Jeff: A najgorszy przypadek, a na koniec, naprawdę jestem dla ciebie tylko blokadą, ponieważ składasz bilet, a potem czekasz, aż wrócę z lunchu. Wróciłem z lunchu, ale mam inne rzeczy do zrobienia. Powiedzieliśmy: „Jak możemy to zautomatyzować, abyśmy mogli przekazać to w ręce programistów, jednocześnie rozwiązując którekolwiek z tych obaw związanych z audytem, ​​które możemy mieć?”

Jeff: Umieściliśmy to w przepływie pracy JIRA, gdzie mieliśmy bota, który automatyzował wykonywanie poleceń określonych w bilecie JIRA. A potem moglibyśmy określić w zgłoszeniu JIRA, że wymaga on zatwierdzenia przez jednego z kilku starszych inżynierów. Prawidłowy.

Jeff: Bardziej sensowne jest to, że inżynier zatwierdza pracę innego inżyniera, ponieważ mają kontekst. Prawidłowy. Nie muszą siedzieć i czekać na operacje. Otrzymano odpowiedź na element kontroli, ponieważ mamy przejrzysty przepływ pracy, który został zdefiniowany w JIRA, który jest dokumentowany po zatwierdzeniu przez kogoś, zgodnie z żądaniem. I mamy automatyzację, która pobiera to polecenie i wykonuje je dosłownie w terminalu. Prawidłowy.

Jeff: Nie musisz się martwić, że popełnię błąd. Nie musisz się martwić, że złapię niewłaściwy bilet. To wydłużyło czas realizacji tych biletów, mniej więcej dziesięciokrotnie. Prawidłowy. Deweloperzy są odblokowani. Mój zespół nie jest przy tym związany. A tak naprawdę zajęło tylko tydzień lub dwa tygodnie, aby faktycznie opracować automatyzację i uprawnienia niezbędne do uzyskania do niej dostępu.

Jeff: Teraz jesteśmy z tego całkowicie usunięci. A rozwój jest w stanie zlecić część tej funkcjonalności niższym częściom organizacji. Zepchnęli to do obsługi klienta. To tak, jak teraz, gdy obsługa klienta wie, że ten rekord musi zostać zaktualizowany o cokolwiek, nie potrzebują rozwoju. Mogą przesłać swój standardowy skrypt, który zatwierdziliśmy dla tej funkcji. I mogą przeprowadzić go dokładnie w tym samym przepływie pracy, co programowanie. To naprawdę dobrodziejstwo.

Jeff: A potem pozwala nam spychać pracę coraz niżej w całej organizacji. Ponieważ jak to robimy, praca staje się coraz tańsza, ponieważ mógłbym mieć wymyślnego, drogiego programistę, który to prowadzi. Prawidłowy. Lub mogę poprosić osobę z działu obsługi klienta, która pracuje bezpośrednio z klientem, sama ją uruchamia, gdy rozmawia przez telefon z klientem, który rozwiązuje problem.

Jeff: Myślę, że automatyzacja jest kluczem do każdej organizacji. I ostatni punkt, o którym powiem, jest taki, że pozwala również eksportować wiedzę ekspercką. Prawidłowy. Teraz mogę być jedyną osobą, która wie, jak to zrobić, jeśli potrzebuję wykonać kilka poleceń w wierszu poleceń. Ale jeśli włączę to w automatyzację, mogę to dać każdemu. A ludzie wiedzą, jaki jest wynik końcowy, ale nie muszą znać wszystkich etapów pośrednich. Dziesięciokrotnie zwiększyłem swoją wartość, wypychając ją do organizacji, wykorzystując moją wiedzę i kodyfikując ją w coś, co można wyeksportować.

Drew: Mówiłeś o automatyzacji zadań, które często się zdarzają. Czy istnieje argument za automatyzacją zadań, które zdarzają się tak rzadko, że programista potrzebuje dużo czasu, aby szybko się zorientować, jak to powinno działać? Ponieważ wszyscy są zapomniani. To trwało tak długo. Minął rok, może nikt wcześniej tego nie robił. Czy istnieje argument za automatyzacją tego typu rzeczy?

Jeff: To trudne zachowanie równowagi. Prawidłowy. I zawsze mówię, bierz to z osobna. A powodem, dla którego to mówię, jest to, że jedną z mantr w DevOps jest to, że jeśli coś jest bolesne, rób to częściej. Prawidłowy. Ponieważ im częściej to robisz, tym większa staje się pamięć mięśniowa i możesz ćwiczyć i eliminować te załamania.

Jeff: Problem, który widzimy w przypadku automatyzacji bardzo rzadkich zadań, polega na tym, że krajobraz środowiska ma tendencję do zmiany pomiędzy wykonaniami tej automatyzacji. Prawidłowy. To, co w końcu się dzieje, to fakt, że Twój kod przyjmuje określone założenia dotyczące środowiska, a te założenia nie są już aktualne. Tak więc automatyzacja i tak się psuje.

Drew: A potem masz dwa problemy.

Jeff: Dobrze. Prawidłowy. Dokładnie tak. Dokładnie tak. A ty powiesz: „Czy napisałem to źle? Czy to jest? Nie, ta rzecz jest naprawdę zepsuta. Więc-

Jeff: Źle wpisujesz, czy to nie, ta rzecz jest faktycznie zepsuta. Więc jeśli chodzi o automatyzację rzadkich zadań, naprawdę bierzemy pod uwagę każdy przypadek z osobna, aby zrozumieć, cóż, jakie jest ryzyko, jeśli to nie zadziała, prawda. Jeśli popełnimy błąd, czy jesteśmy w złym stanie, czy po prostu nie zakończyliśmy tego zadania? Jeśli więc możesz mieć pewność, że zawiodłoby to z wdziękiem i nie miało negatywnego wpływu, warto spróbować zautomatyzować to. Ponieważ przynajmniej wtedy masz ramy rozumienia tego, co powinno się dziać, ponieważ przynajmniej ktoś będzie w stanie przeczytać kod i zrozumieć, w porządku, to właśnie robiliśmy. I nie rozumiem, dlaczego to już nie działa, ale mam jasne zrozumienie tego, co miało się stać, przynajmniej na podstawie czasu projektowania, kiedy to zostało napisane.

Jeff: Ale jeśli kiedykolwiek znajdziesz się w sytuacji, w której awaria może doprowadzić do zmiany danych lub czegoś podobnego, zwykle błądzę po stronie ostrożności i trzymam to ręcznie tylko dlatego, że jeśli mam skrypt automatyzacji, jeśli znajdę jakiś dokument zbieżności ma trzy lata i mówi, że uruchamiam ten skrypt, mam tendencję do stuprocentowego zaufania do tego skryptu i go wykonuję. Prawidłowy. Podczas gdy jeśli jest to seria ręcznych kroków, które zostały udokumentowane cztery lata temu, będę taki, że muszę tutaj przeprowadzić pewną weryfikację. Prawidłowy? Pozwól, że przejdę przez to trochę i porozmawiam z kilkoma osobami. A czasami, kiedy projektujemy procesy, warto wymusić ten proces myślowy, prawda? I musisz pomyśleć o ludzkim komponencie io tym, jak będą się zachowywać. A czasami warto uczynić ten proces trochę bardziej kłopotliwym, aby zmusić ludzi do myślenia, czy powinienem to robić teraz?

Drew: Czy istnieją inne sposoby identyfikowania tego, co powinno być zautomatyzowane, poprzez monitorowanie systemów i mierzenie rzeczy? To znaczy, myślę o DevOps i myślę o dashboardach jako o jednej z rzeczy, ładnych wykresów. Jestem pewien, że w tych pulpitach nawigacyjnych jest o wiele więcej niż tylko ładny wygląd, ale zawsze fajnie jest mieć ładnie wyglądające pulpity nawigacyjne. Czy istnieją sposoby mierzenia tego, co robi system, aby pomóc w podejmowaniu tego rodzaju decyzji?

Jeff: Absolutnie. I tego rodzaju przechodzenie do części metrykalnych kamer, prawda, to co śledzimy w naszych systemach, aby wiedzieć, że działają wydajnie? A jedną z najczęstszych pułapek metryk jest szukanie błędów zamiast weryfikowania sukcesu. A to są dwie bardzo różne praktyki, prawda? Coś więc może przepływać przez system i niekoniecznie błąd, ale niekoniecznie przejść przez cały proces tak, jak powinien. Więc jeśli upuszczamy wiadomość do kolejki wiadomości, powinna istnieć odpowiednia metryka, która mówi: „I ta wiadomość została pobrana i przetworzona”, prawda? Jeśli nie, to prawda, szybko stracisz równowagę, a system nie będzie działał tak, jak powinien. Myślę, że możemy wykorzystać metryki jako sposób na zrozumienie różnych rzeczy, które powinny być zautomatyzowane, gdy wejdziemy w te złe stany.

Jeff: Prawda? Ponieważ często jest to bardzo prosty krok, który należy wykonać, aby posprzątać, prawda? Dla ludzi, którzy przez jakiś czas byli operatorami, prawda, alert przestrzeni dyskowej, wszyscy o tym wiedzą. Och, mamy już dysk. Och, zapomnieliśmy, że jest koniec miesiąca i naliczanie opłat jest naliczane, a naliczanie zawsze wypełnia logi. A potem log VAR zajmuje całe miejsce na dysku, więc musimy uruchomić rotację logu. Prawidłowy? Możesz obudzić się o trzeciej nad ranem, jeśli masz takie preferencje. Ale jeśli wiemy, że to jest zachowanie, nasze metryki powinny być w stanie dać nam wskazówkę do tego. I możemy po prostu zautomatyzować polecenie obracania dziennika, prawda? Och, osiągnęliśmy ten próg, wykonaj polecenie obracania dziennika. Zobaczmy, czy alert zostanie usunięty. Jeśli tak, kontynuuj życie. Jeśli nie, to może kogoś obudzimy, prawda.

Jeff: Widzisz to znacznie częściej również w przypadku automatyzacji infrastruktury, właśnie wtedy jest tak: „Hej, czy nasze żądania na sekundę osiągają nasze teoretyczne maksimum. Może musimy przeskalować klaster. Może musimy dodać trzy lub cztery węzły do ​​puli systemów równoważenia obciążenia”. I możemy to zrobić bez konieczności interwencji kogoś. Możemy po prostu spojrzeć na te metryki i podjąć to działanie, a następnie zakontraktować tę infrastrukturę, gdy spadnie ona poniżej określonego progu, ale musisz mieć te metryki i te punkty zaczepienia w środowisku monitorowania, aby móc to zrobić. I tu właśnie pojawia się cała metryczna część rozmowy.

Jeff: Poza tym dobrze jest też móc dzielić się tymi informacjami z innymi ludźmi, ponieważ kiedy masz dane, możesz zacząć rozmawiać o rzeczach we wspólnej rzeczywistości, prawda, ponieważ zajęty to termin ogólny, ale 5200 żądań na sekundę to dużo bardziej konkretna, o której wszyscy możemy się przekonać. I myślę, że tak często, gdy rozmawiamy o pojemności lub czymkolwiek innym, używamy tych falujących określeń, podczas gdy zamiast tego moglibyśmy patrzeć na pulpit nawigacyjny i podawać bardzo konkretne wartości i upewniać się, że wszyscy mają dostęp do tych pulpitów nawigacyjnych, że they're not hidden behind some ops wall that only we have access to for some unknown reason.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Prawidłowy. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Prawidłowy.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Czy to uczciwa ocena?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Prawidłowy. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Prawidłowy. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Prawidłowy. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Prawidłowy. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Prawidłowy? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Prawidłowy. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Prawidłowy. So you could be doing any manner of testing in there that is extremely complicated. Prawidłowy. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Prawidłowy. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Prawidłowy. Let me get Drew on the phone and see what's going on.” Prawidłowy. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Prawidłowy. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Prawidłowy. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Chciałem napisać do nich, głównie indywidualnych współpracowników i menedżerów średniego szczebla, aby powiedzieć: „Nie musisz być dyrektorem ds. technicznych, aby móc dokonywać tego rodzaju stopniowych zmian, i nie musisz tego mieć cała rewolucja sprzedażowa, aby móc czerpać korzyści z DevOps.” Więc to był dla nich rodzaj listu miłosnego, który powiedział: „Hej, możesz to zrobić w kawałkach. Możesz to zrobić sam. Są też wszystkie te rzeczy, o których możesz nie myśleć, że są związane z DevOps, ponieważ myślisz o nich jako o narzędziach i Kubernetes”. Nie każda organizacja… Gdybyś był za stanem Nowy Jork, tak jak rząd stanowy, nie wszedłbyś tak po prostu i wprowadził Kubernetes z dnia na dzień. Prawidłowy? Możesz jednak zaimplementować sposób, w jaki zespoły rozmawiają ze sobą, jak współpracują, jak rozumiemy swoje problemy i jak możemy rozwiązać te problemy poprzez automatyzację. Są to rzeczy, które znajdują się w Twojej strefie wpływów, które mogą poprawić Twoje codzienne życie.

Jeff: Więc to był naprawdę list do tych ludzi, ale myślę, że jest tam wystarczająco dużo danych i wystarczająco informacji, aby ludzie, którzy są w organizacji DevOps, mogli zebrać i powiedzieć: „Hej, to nadal jest dla nas przydatne. ” I wielu ludzi, jak sądzę, szybko identyfikuje się po przeczytaniu książki, że nie są w organizacji DevOps, po prostu mają zmianę stanowiska. I to się często zdarza. Mówią więc: „Hej, teraz jesteśmy inżynierami DevOps, ale nie wykonujemy tego rodzaju praktyk, o których mowa w tej książce i jak się tam dostaniemy?”

Drew: Wygląda na to, że twoja książka jest jedną z nich, ale czy są inne zasoby, do których ludzie chcący zacząć korzystać z DevOps mogą sięgnąć? Czy są dobre miejsca do nauki tych rzeczy?

Jeff: Tak. Myślę, że DevOps For Dummies Emily Freeman to świetne miejsce na start. Naprawdę świetnie radzi sobie z układaniem niektórych podstawowych koncepcji i pomysłów oraz tego, do czego dążymy. Tak więc byłoby to dobre miejsce na początek, po prostu po to, by trochę ukształtować teren. Myślę, że Projekt Phoenix to oczywiście kolejne świetne źródło Gene'a Kima. I to jest świetne, to pewnego rodzaju przygotowuje grunt pod typy problemów, które mogą tworzyć nie będąc w środowisku DevOps. I świetnie się spisuje, uwydatniając te wzorce i osobowości, które pojawiają się wielokrotnie we wszystkich typach organizacji. Myślę, że świetnie to uwydatnia. A jeśli przeczytasz tę książkę, myślę, że skończysz krzycząc na stronach mówiąc: „Tak, tak. Ten. Ten." To kolejne świetne miejsce.

Jeff: A potem od tego momentu, zagłębiając się w którykolwiek z podręczników DevOps. Mam zamiar się kopnąć za to, że to powiedziałem, ale podręcznik Google SRE był kolejnym świetnym miejscem do obejrzenia. Zrozum, że nie jesteś Google, więc nie wydaje ci się, że musisz wszystko wdrażać, ale myślę, że wiele ich pomysłów i strategii jest rozsądnych dla każdej organizacji i są świetnymi miejscami, w których możesz coś zrobić i powiedzieć coś w stylu: „Dobra, zamierzamy sprawić, by nasze środowisko operacyjne było trochę bardziej wydajne”. I to jest, myślę, że będzie to szczególnie istotne dla programistów, którzy odgrywają rolę ops, ponieważ skupia się na wielu rodzajach programistycznego podejścia do rozwiązywania niektórych z tych problemów.

Drew: Więc nauczyłem się wszystkiego o DevOps. O czym się ostatnio dowiedziałeś, Jeff?

Jeff: Kubernetes, stary. Tak. Kubernetes był dla nas prawdziwym źródłem czytania i wiedzy. Dlatego obecnie staramy się to zaimplementować w Centro, jako sposób na dalsze wzmocnienie programistów. Chcemy pójść o krok dalej od miejsca, w którym się znajdujemy. Mamy dużo automatyzacji, ale teraz, jeśli chodzi o wdrażanie nowej usługi, mój zespół nadal jest w to mocno zaangażowany, w zależności od charakteru usługi. A my nie chcemy pracować w tym zawodzie. Chcemy, aby programiści byli w stanie przenieść pomysł od koncepcji przez kod do wdrożenia i robić to tam, gdzie wiedza operacyjna jest skodyfikowana w systemie. Tak więc, kiedy poruszasz się po systemie, system Cię prowadzi. Uważamy więc, że Kubernetes jest narzędziem, które nam w tym pomoże.

Jeff: To jest po prostu niesamowicie skomplikowane. I jest to duży kawałek do odgryzienia. Zastanawiasz się, jak wyglądają wdrożenia? Jak wykorzystujemy tych operatorów w Kubernetes? Jak wygląda CICD w tym nowym świecie? Więc było dużo czytania, ale w tej dziedzinie ciągle się uczysz, prawda? Nie ma znaczenia, jak długo w tym jesteś, jak długo to robisz, jesteś gdzieś idiotą w jakimś aspekcie tej dziedziny. Więc jest to po prostu coś, do czego się przystosowujesz

Drew: Cóż, czapki z głów, jak mówię, nawet po tylu latach, chociaż rozumiem, gdzie to jest w stosie, nadal naprawdę nie mam pojęcia, co robi Kubernetes.

Jeff: Czasami czuję się podobnie. Wydaje się, że robi wszystkiego po trochu, prawda? To DNS XXI wieku.

Drew: Jeśli ty, słuchacz, chciałbyś usłyszeć więcej od Jeffa, możesz znaleźć go na Twitterze, gdzie jest mroczny i nerdowy, a także jego książkę i linki do poprzednich prezentacji i wpisów na blogu na jego stronie, reachabledevops.com. Dzięki za przyłączenie się do nas dzisiaj, Jeff. Czy miałeś jakieś słowa pożegnalne?

Jeff: Po prostu ucz się dalej, po prostu idź tam, ucz się dalej i rozmawiaj z innymi rówieśnikami. Mów, mów, mów. Im więcej możesz rozmawiać z ludźmi, z którymi pracujesz, tym lepsze zrozumienie, tym większą dla nich empatię wytworzysz, a jeśli w organizacji jest ktoś, kogo nienawidzisz, porozmawiaj najpierw z nim.