Pytanie „jak wdrożyć devops” pojawia się od lat, ale nie ma zbyt wielu dobrych materiałów. Czasami padasz ofiarą reklam niezbyt inteligentnych konsultantów, którzy muszą sprzedać swój czas za wszelką cenę. Czasami są to niejasne, niezwykle ogólne słowa o tym, jak statki megakorporacji orają przestrzenie wszechświata. Powstaje pytanie: jakie to ma dla nas znaczenie? Drogi autorze, czy możesz jasno sformułować swoje pomysły na liście?
Wszystko to wynika z faktu, że nie zgromadziło się zbyt wiele realnej praktyki i zrozumienia skutków przemian kultury firmy. Zmiany w kulturze to sprawa długoterminowa, której rezultaty nie pojawią się za tydzień czy miesiąc. Potrzebujemy kogoś na tyle dorosłego, aby widział, jak firmy budowano i upadały na przestrzeni lat.
Johna Willisa - jeden z ojców DevOps. John ma dziesiątki lat doświadczenia w pracy z ogromną liczbą firm. Ostatnio John zaczął dostrzegać określone wzorce, jakie zachodzą podczas pracy z każdym z nich. Korzystając z tych archetypów, John prowadzi firmy na prawdziwą ścieżkę transformacji DevOps. Więcej o tych archetypach przeczytasz w tłumaczeniu jego raportu z konferencji DevOops 2018.
O głośniku:
Ponad 35 lat zarządzania IT, brał udział w tworzeniu poprzednika OpenCloud w Canonical, brał udział w 10 startupach, z czego dwa zostały sprzedane firmom Dell i Docker. Obecnie jest wiceprezesem ds. DevOps i praktyk cyfrowych w SJ Technologies.
Następna historia z punktu widzenia Johna.
Nazywam się John Willis i najłatwiej mnie znaleźć na Twitterze, . Mam ten sam alias w Gmailu i GitHubie. A znajdziesz dla nich nagrania wideo moich raportów i prezentacji.
Mam wiele spotkań z CIO różnych dużych firm. Bardzo często narzekają, że nie rozumieją, czym jest DevOps, a każdy, kto próbuje im to wytłumaczyć, mówi o czymś innym. Inną częstą skargą jest to, że DevOps nie działa, choć wydaje się, że dyrektorzy robią wszystko tak, jak im wyjaśniono. Mówimy o dużych firmach, które mają ponad sto lat. Po rozmowach z nimi doszedłem do wniosku, że w przypadku wielu problemów najlepiej sprawdzi się nie zaawansowana technologia, ale raczej rozwiązania stosunkowo low-tech. Przez tygodnie po prostu rozmawiałem z ludźmi z różnych działów. To co widzicie na pierwszym zdjęciu w poście to mój ostatni projekt, tak wygląda pokój po trzech dniach pracy.
Co to jest DevOps?
Rzeczywiście, jeśli zapytasz 10 różnych osób, dadzą 10 różnych odpowiedzi. Ale oto interesująca rzecz: wszystkie dziesięć odpowiedzi będzie poprawnych. Nie ma tu złej odpowiedzi. Byłem dość głęboko zaangażowany w DevOps przez około 10 lat i byłem pierwszym Amerykaninem na pierwszym DevOpsDay. Nie powiem, że jestem mądrzejszy od wszystkich zaangażowanych w DevOps, ale mało kto włożył w to tyle wysiłku. Wierzę, że DevOps pojawia się, gdy kapitał ludzki i technologia łączą się. Często zapominamy o wymiarze ludzkim, chociaż dużo mówimy o różnych kulturach.
Teraz mamy mnóstwo danych, pięć lat badań akademickich, testowanie teorii na skalę przemysłową. Badania te mówią nam, że jeśli połączysz pewne wzorce zachowań w kulturze organizacyjnej, możesz osiągnąć 2000-krotne przyspieszenie. Przyspieszeniu temu towarzyszy jednakowa poprawa stabilności. Jest to ilościowy pomiar korzyści, jakie DevOps może przynieść każdej firmie. Kilka lat temu rozmawiałem o DevOps z dyrektorem generalnym firmy z listy Fortune 5000. Przygotowując się do prezentacji, byłem bardzo zdenerwowany, ponieważ musiałem podsumować swoje wieloletnie doświadczenie w 5 minut.
Na koniec podałem co następuje Definicja DevOps: Jest to zbiór praktyk i wzorców, które umożliwiają przekształcenie kapitału ludzkiego w kapitał organizacyjny o wysokiej wydajności. Przykładem jest sposób, w jaki Toyota działała przez ostatnie 50 czy 60 lat.
(W dalszej części takie diagramy służą nie jako materiał odniesienia, ale jako ilustracje. Ich treść będzie inna dla każdej nowej firmy. Jednakże obraz można obejrzeć osobno i powiększyć
Jedną z najbardziej skutecznych takich praktyk jest mapowanie wartości strumienia. Napisano na ten temat kilka dobrych książek, z których najbardziej udana jest autorstwa Karen Martin. Ale w ciągu ostatniego roku doszedłem do wniosku, że nawet takie podejście jest zbyt zaawansowane technologicznie. Na pewno ma wiele zalet i często z niego korzystałem. Kiedy jednak dyrektor generalny pyta, dlaczego jego firma nie może przejść na nowe szyny, jest za wcześnie, aby mówić o mapowaniu strumienia wartości. Jest wiele znacznie bardziej fundamentalnych pytań, na które należy najpierw odpowiedzieć.
Myślę, że błędem wielu moich kolegów jest to, że po prostu przekazują firmie pięciopunktowy przewodnik, a następnie wracają po sześciu miesiącach i sprawdzają, co się stało. Nawet dobry schemat, taki jak mapowanie strumienia wartości, ma, powiedzmy, słabe punkty. Po setkach wywiadów z dyrektorami różnych firm opracowałem pewien schemat, który pozwala rozłożyć problem na jego składowe, a teraz omówimy po kolei każdy z tych elementów. Przed zastosowaniem jakichkolwiek rozwiązań technologicznych wykorzystuję ten wzór i w rezultacie wszystkie moje ściany pokryte są schematami. Ostatnio współpracowałem z funduszem inwestycyjnym i skończyłem na 100-150 takich programach.
Zła kultura zjada dobre podejście do śniadania
Główna idea jest taka: żadna ilość Lean, Agile, SAFE i DevOps nie pomoże, jeśli sama kultura organizacji jest zła. To jak nurkowanie na głębokość bez sprzętu do nurkowania lub działanie bez prześwietlenia rentgenowskiego. Innymi słowy, parafrazując Druckera i Deminga: zła kultura organizacyjna pochłonie każdy dobry system, nie dławiąc się nim.
Aby rozwiązać ten główny problem, musisz wykonać następujące kroki:
- Spraw, aby cała praca była widoczna: musisz sprawić, aby cała praca była widoczna. Nie w tym sensie, że musi koniecznie zostać wyświetlony na jakimś ekranie, ale w tym sensie, że musi być obserwowalny.
- Skonsolidowane systemy zarządzania pracą: systemy zarządzania wymagają konsolidacji. W problemie wiedzy „plemiennej” i wiedzy instytucjonalnej w 9 przypadkach na 10 wąskim gardłem są ludzie. W książce problem dotyczył jednej osoby, Brenta, przez co projekt opóźnił się o trzy lata. I wszędzie spotykam tych „Brentów”. Aby rozwiązać te wąskie gardła, korzystam z dwóch kolejnych pozycji z naszej listy.
- Metodologia teorii ograniczeń: teoria ograniczeń.
- Hacki na współpracę: hacki do współpracy.
- Toyota Kata (): O Toyocie Kata nie będę dużo mówił. Jeśli jesteś zainteresowany, na moim githubie na prawie każdy z tych tematów.
- Organizacja zorientowana na rynek: organizacja zorientowana na rynek.
- Audytorzy z przesunięciem w lewo: audyt na wczesnych etapach cyklu.
Pracę z organizacją zaczynam bardzo prosto: idę do firmy i rozmawiam z pracownikami. Jak widać, nie ma wysokiej technologii. Jedyne, czego potrzebujesz, to coś, na czym możesz pisać. Gromadzę kilka zespołów w jednym pomieszczeniu i analizuję to, co mi mówią, z perspektywy moich 7 archetypów. A potem sam daję im marker i proszę, żeby zapisali na tablicy wszystko, co do tej pory powiedzieli na głos. Zwykle na tego typu spotkaniach jest jedna osoba, która wszystko zapisuje, a co najwyżej jest w stanie spisać 10% dyskusji. Dzięki mojej metodzie liczbę tę można podnieść do około 40%.
(Tę ilustrację można oglądać osobno )
Moje podejście opiera się na pracach Williama Schneidera. ). Podejście opiera się na założeniu, że każdą organizację można podzielić na cztery kwadraty. Dla mnie ten schemat jest zwykle wynikiem pracy z setkami innych schematów, które pojawiają się podczas analizy organizacji. Załóżmy, że mamy organizację o wysokim poziomie kontroli, ale o niskich kompetencjach. Jest to opcja wyjątkowo niepożądana: gdy wszyscy trzymają się ustalonych zasad, ale nikt nie wie, co robić.
Nieco lepszą opcją jest ta charakteryzująca się wysokim poziomem kontroli i kompetencji. Jeśli taka firma jest rentowna, to być może nie potrzebuje DevOps. Najciekawiej jest pracować z firmą, która ma wysoki poziom kontroli, niskie kompetencje i współpracę, ale jednocześnie wysoki poziom kultury (kultywacji). Oznacza to, że w firmie jest dużo ludzi, którzy lubią w niej pracować, a rotacja pracowników jest niska.
(Tę ilustrację można oglądać osobno )
Wydaje mi się, że metody oparte na sztywnych wytycznych w końcu stają na drodze do osiągnięcia prawdy. Szczególnie w przypadku mapowania strumienia wartości istnieje wiele zasad dotyczących struktury informacji. Na wczesnych etapach pracy, o których teraz mówię, te zasady nie są nikomu potrzebne. Jeśli osoba z markerem w dłoniach opisuje na tablicy rzeczywistą sytuację w firmie, jest to najlepszy sposób na zrozumienie stanu rzeczy. Taka informacja nie dociera do dyrektorów. W tej chwili głupio jest przerywać osobie i mówić, że nieprawidłowo narysował jakąś strzałę. Na tym etapie lepiej zastosować się do prostych zasad, np. wielopoziomową abstrakcję można stworzyć po prostu za pomocą wielokolorowych pisaków.
Powtarzam, żadnej zaawansowanej technologii. Czarny znacznik przedstawia obiektywną rzeczywistość tego, jak wszystko działa. Czerwonym markerem ludzie zaznaczają, co im się nie podoba w obecnym stanie rzeczy. Ważne, żeby to oni to napisali, a nie ja. Kiedy po spotkaniu idę do CIO, nie oferuję listy 10 rzeczy, które należy naprawić. Staram się znajdować powiązania pomiędzy tym, co mówią ludzie w firmie, a istniejącymi, sprawdzonymi wzorcami. Na koniec niebieski znacznik sugeruje możliwe rozwiązania problemu.
(Tę ilustrację można oglądać osobno )
Przykład takiego podejścia przedstawiono powyżej. Na początku tego roku współpracowałem z jednym bankiem. Pracownicy ochrony byli przekonani, że nie powinni przychodzić na projekt i przeglądanie wymagań.
(Tę ilustrację można oglądać osobno )
A potem rozmawialiśmy z osobami z innych działów i okazało się, że jakieś 8 lat temu programiści zwolnili pracowników ochrony, bo spowalniali pracę. A potem zamieniło się to w zakaz, który uznawano za coś oczywistego. Chociaż w rzeczywistości nie było zakazu.
Nasze spotkanie przebiegło w niezwykle zagmatwany sposób: przez około trzy godziny pięć różnych zespołów nie było mi w stanie wyjaśnić, co dzieje się pomiędzy kodem a zgromadzeniem. I to wydawałoby się najprostszą rzeczą. Większość konsultantów DevOps z góry zakłada, że wszyscy już to wiedzą.
Wtedy osoba odpowiedzialna za ład IT, która milczała przez cztery godziny, nagle ożyła, gdy dotarliśmy do jej tematu i zajęła nas na bardzo długi czas. Na koniec zapytałem go, co sądzi o spotkaniu i nigdy nie zapomnę jego odpowiedzi. Powiedział: „Kiedyś myślałem, że nasz bank ma tylko dwa sposoby dostarczania oprogramowania, ale teraz wiem, że jest ich pięć, a o trzech nawet nie wiedziałem”.
(Tę ilustrację można oglądać osobno )
Ostatnie spotkanie w tym banku odbyło się z zespołem oprogramowania inwestycyjnego. To przy niej okazało się, że pisanie diagramów markerem na kartce papieru jest lepsze niż na tablicy, a nawet lepsze niż na smartboardzie.
Zdjęcia, które widzicie przedstawiają jak wyglądała hotelowa sala konferencyjna czwartego dnia naszego spotkania. I na tych schematach szukaliśmy wzorców, czyli archetypów.
Zadaję więc pracownikom pytania, a oni zapisują odpowiedzi markerami w trzech kolorach (czarnym, czerwonym i niebieskim). Analizuję ich odpowiedzi pod kątem archetypów. Omówmy teraz wszystkie archetypy w kolejności.
1. Spraw, aby cała praca była widoczna: Spraw, aby praca była widoczna
Większość firm, z którymi współpracuję, ma bardzo wysoki odsetek nieznanych prac. Na przykład ma to miejsce wtedy, gdy jeden pracownik przychodzi do drugiego i po prostu prosi o zrobienie czegoś. W dużych organizacjach może być 60% pracy nieplanowanej. A aż 40% prac nie jest w żaden sposób udokumentowane. Gdyby to był Boeing, nigdy w życiu nie wsiadłbym na pokład ich samolotu. Jeśli udokumentowana jest tylko połowa pracy, nie wiadomo, czy praca ta jest wykonywana prawidłowo, czy nie. Wszystkie inne metody okazują się bezużyteczne – nie ma sensu próbować niczego automatyzować, bo znane 50% może być najbardziej spójną i przejrzystą częścią pracy, której automatyzacja nie da świetnych efektów, a wszystko najgorsze rzeczy są w niewidzialnej połowie. W przypadku braku dokumentacji nie da się znaleźć wszelkiego rodzaju hacków i ukrytej pracy, a nie znaleźć wąskich gardeł, tych właśnie „Brentów”, o których już mówiłem. Jest taka wspaniała książka Dominiki DeGrandis . Ona odkrywa pięć różnych „wycieków czasu” (złodzieje czasu):
- Za dużo pracy w toku (WIP)
- Nieznane zależności
- Nieplanowana praca
- Sprzeczne priorytety
- Zaniedbana praca
To bardzo cenna analiza, a książka jest świetna, ale wszystkie te porady są bezużyteczne, jeśli widoczne jest tylko 50% danych. Metody zaproponowane przez Dominikę można zastosować, jeśli uzyskana zostanie dokładność powyżej 90%. Mówię o sytuacjach, gdy szef daje podwładnemu zadanie na 15 minut, ale zajmuje mu to trzy dni; ale szef tak naprawdę nie wie, że ten podwładny jest zależny od czterech lub pięciu innych osób.
Projekt Phoenix to wspaniała opowieść o projekcie, który spóźnił się o trzy lata. Jednemu z bohaterów grozi za to zwolnienie i spotyka się z innym bohaterem, przedstawianym jako swego rodzaju Sokrates. Pomaga ustalić, co dokładnie poszło nie tak. Okazuje się, że firma ma jednego administratora systemu, który nazywa się Brent i cała praca jakoś przechodzi przez niego. Na jednym ze spotkań jeden z podwładnych zostaje zapytany: dlaczego każde półgodzinne zadanie zajmuje tydzień? Odpowiedzią jest bardzo uproszczone przedstawienie teorii kolejek i prawa Little'a, w którym okazuje się, że przy obłożeniu 90% każda godzina pracy zajmuje 9 godzin. Każde zadanie należy wysłać do siedmiu innych osób, tak aby godzina wyniosła 63 godziny, 7 razy 9. Mówię tylko, że aby skorzystać z prawa Little'a lub jakiejkolwiek złożonej teorii kolejkowania, trzeba przynajmniej mieć dane.
Kiedy więc mówię o widoczności, nie mam na myśli tego, że wszystko jest na ekranie, ale że przynajmniej masz dane. Kiedy to robią, często okazuje się, że istnieje bardzo duża ilość nieplanowanej pracy, która w jakiś sposób jest wysyłana do Brenta, gdy nie jest ona potrzebna. A Brent to świetny facet, nigdy nie odmówi, ale nikomu nie mówi, jak wykonuje swoją pracę.
Kiedy praca jest widoczna, można uporządkować dane (tak właśnie robi Dominika na zdjęciu), zastosować abstrakcję pięciu wycieków czasowych i zastosować automatyzację.
2. Skonsoliduj systemy zarządzania pracą: zarządzanie zadaniami
Archetypy, o których mówię, to rodzaj piramidy. Jeśli pierwszy zostanie wykonany poprawnie, to drugi jest już rodzajem dodatku. Wiele z nich nie sprawdza się w przypadku start-upów. Należy o nich pamiętać w przypadku większych firm, takich jak Fortune 5000. Ostatnia firma, w której pracowałem, miała 10 systemów biletowych. Jeden zespół miał Remedy, inny napisał jakiś własny system, trzeci korzystał z Jiry, a jeszcze inni korzystali z poczty elektronicznej. Ten sam problem pojawia się, jeśli firma ma 30 różnych rurociągów, ale nie mam czasu na omawianie wszystkich takich przypadków.
Omawiam z ludźmi dokładnie, w jaki sposób tworzone są bilety, co dzieje się z nimi dalej i jak można je obejść. Najciekawsze jest to, że ludzie na naszych spotkaniach mówią całkiem szczerze. Zapytałem, ile osób umieściło określenie „niewielki/brak wpływu” na biletach, którym w rzeczywistości należy nadać „duży wpływ”. Okazało się, że prawie wszyscy tak robią. Nie wdaję się w donosy i na wszelkie możliwe sposoby staram się nie identyfikować osób. Kiedy szczerze mi coś wyznają, nie zdradzam tej osoby. Ale kiedy prawie wszyscy omijają system, oznacza to, że całe bezpieczeństwo to w zasadzie ozdoba okienna. Dlatego z danych tego systemu nie można wyciągać żadnych wniosków.
Aby rozwiązać problem z biletami, musisz wybrać jeden główny system. Jeśli używasz Jira, zachowaj Jira. Jeśli jest jakakolwiek alternatywa, niech będzie to jedyna. Konkluzja jest taka, że bilety należy postrzegać jako kolejny krok w procesie rozwoju. Każde działanie musi mieć bilet, który musi przejść przez proces programowania. Zgłoszenia wysyłane są do zespołu, który umieszcza je na scenorysie, a następnie bierze za nie odpowiedzialność.
Dotyczy to wszystkich działów, w tym infrastruktury i operacji. W takim przypadku możliwe jest sformułowanie przynajmniej wiarygodnego wyobrażenia o stanie rzeczy. Po ustaleniu tego procesu ustalenie, kto jest odpowiedzialny za każdą aplikację, staje się nagle łatwe. Bo teraz otrzymujemy nie 50%, a 98% nowych usług. Jeśli ten podstawowy proces zadziała, dokładność w całym systemie ulegnie poprawie.
Rurociąg usług
To znowu dotyczy tylko dużych korporacji. Jeśli jesteś nową firmą na nowym polu, zakasz rękawy i pracuj ze swoim Travis CI lub CircleCI. Jeśli chodzi o firmy z listy Fortune 5000, przykładem może być sytuacja w banku, w którym pracowałem. Przyszedł do nich Google i pokazano im schematy starych systemów IBM. Chłopaki z Google zapytali zdezorientowani - gdzie jest kod źródłowy tego? Ale nie ma kodu źródłowego, nawet GUI. Oto rzeczywistość, z którą muszą sobie radzić duże organizacje: 40-letnie wyciągi bankowe na starym komputerze mainframe. Jeden z moich klientów korzysta z kontenerów Kubernetes z wzorcami Circuit Breaker oraz Chaos Monkey, a wszystko to na potrzeby aplikacji KeyBank. Jednak te kontenery ostatecznie łączą się z aplikacją COBOL.
Faceci z Google byli całkowicie pewni, że rozwiążą wszystkie problemy mojego klienta, a potem zaczęli zadawać pytania: czym jest datapipe IBM? Mówi się im: to jest złącze. Z czym to się łączy? Do układu Sperry’ego. A co to jest? I tak dalej. Na pierwszy rzut oka wydaje się: jaki może być rodzaj DevOps? Ale w rzeczywistości jest to możliwe. Istnieją systemy dostaw, które umożliwiają przekazanie przepływu pracy zespołom dostawczym.
3. Teoria ograniczeń: Teoria ograniczeń
Przejdźmy do trzeciego archetypu: wiedzy instytucjonalnej/„plemiennej”. Z reguły w każdej organizacji jest kilka osób, które wszystko wiedzą i wszystkim zarządzają. To ci, którzy są w organizacji najdłużej i znają wszystkie obejścia.
Kiedy pojawia się to na diagramie, specjalnie zakreślam takie osoby markerem: na przykład okazuje się, że na wszystkich spotkaniach obecny jest pewien Lou. I dla mnie jest jasne: to lokalny Brent. Kiedy CIO wybiera między mną w T-shirtie i tenisówkach a gościem z IBM w garniturze, zostaje wybrany, ponieważ mogę powiedzieć reżyserowi rzeczy, których drugi facet nie powie, a reżyser może nie chcieć usłyszeć . Mówię im, że wąskim gardłem w ich firmie jest ktoś o imieniu Fred i ktoś o imieniu Lou. Trzeba rozwiązać to wąskie gardło, trzeba od nich w ten czy inny sposób pozyskać wiedzę.
Aby rozwiązać tego typu problem, mogę na przykład zaproponować użycie Slacka. Inteligentny reżyser zapyta – dlaczego? Zazwyczaj w takich przypadkach konsultanci DevOps odpowiadają: bo wszyscy tak robią. Jeśli reżyser jest naprawdę mądry, powie: i co z tego. I tu dialog się kończy. A moja odpowiedź brzmi: ponieważ w firmie są cztery wąskie gardła: Fred, Lou, Susie i Jane. Aby zinstytucjonalizować swoją wiedzę, trzeba najpierw wprowadzić Slacka. Wszystkie wasze wiki to kompletna bzdura, bo nikt nie wie o ich istnieniu. Jeśli zespół inżynierów jest zaangażowany w rozwój front-endu i backendu i każdy musi wiedzieć, że w razie pytań może kontaktować się z zespołem programistów front-endu lub zespołem ds. infrastruktury. Wtedy prawdopodobnie Lou lub Fred będą mieli czas na dołączenie do wiki. A potem w Slacku ktoś może zapytać, dlaczego, powiedzmy, nie działa krok 5. A wtedy Lou lub Fred poprawią instrukcje na wiki. Jeśli ustanowisz ten proces, wiele rzeczy ułoży się samoczynnie.
O to mi właśnie chodzi: żeby rekomendować jakieś wysokie technologie, trzeba najpierw uporządkować pod nie podstawy, a można to zrobić za pomocą opisanych właśnie rozwiązań low-tech. Jeśli zaczniesz od wysokich technologii i nie wyjaśnisz, dlaczego są potrzebne, to z reguły nie kończy się to dobrze. Jeden z naszych klientów korzysta z Azure ML, bardzo taniego i prostego rozwiązania. Na około 30% ich pytań odpowiedziała sama ucząca się maszyna. A tę rzecz napisali operatorzy, którzy nie zajmowali się nauką o danych, statystyką ani matematyką. To jest znaczące. Koszt takiego rozwiązania jest minimalny.
4. hacki do współpracy: hacki do współpracy
Czwartym archetypem jest potrzeba walki z izolacją. Większość ludzi już to wie: izolacja rodzi wrogość. Jeśli każdy dział znajduje się na osobnym piętrze, a ludzie nie krzyżują się ze sobą w żaden sposób, z wyjątkiem windy, wówczas bardzo łatwo pojawia się między nimi wrogość. Ale jeśli wręcz przeciwnie, ludzie są ze sobą w tym samym pokoju, natychmiast wychodzi. Kiedy ktoś rzuca jakiś ogólny zarzut, że np. taki a taki interfejs nigdy nie działa, nie ma nic prostszego do zdekonstruowania takiego oskarżenia. Wystarczy, że programiści, którzy napisali interfejs, zaczną zadawać konkretne pytania, a wkrótce stanie się jasne, że np. użytkownik po prostu nieprawidłowo korzystał z narzędzia.
Sposobów na przezwyciężenie izolacji jest wiele. Kiedyś poproszono mnie o konsultację w sprawie banku w Australii, ale odmówiłem, ponieważ mam dwójkę dzieci i żonę. Jedyne, co mogłem zrobić, aby im pomóc, to polecić graficzne opowiadanie historii. Jest to coś, co zostało udowodnione i działa. Innym ciekawym sposobem są spotkania przy chudej kawie. W dużej organizacji jest to doskonała opcja upowszechniania wiedzy. Ponadto możesz przeprowadzać wewnętrzne devopsdays, hackatony i tak dalej.
5. Kata coachingowe
Jak ostrzegałem na samym początku, nie będę dzisiaj o tym rozmawiać. Jeśli jesteś zainteresowany, możesz rzucić okiem .
Jest też dobra rozmowa na ten temat autorstwa Mike’a Rothera:
6. Zorientowana na rynek: organizacja zorientowana na rynek
Tutaj są różne problemy. Na przykład osoby „I”, osoby „T” i osoby „E”. Ludzie „ja” to ci, którzy robią tylko jedną rzecz. Zwykle istnieją w organizacjach z izolowanymi działami. „T” oznacza, że dana osoba jest dobra w jednej rzeczy, ale jest też dobra w innych. „E” lub nawet „grzebień” ma miejsce, gdy dana osoba ma wiele umiejętności.
Prawo Conwaya działa tutaj (), co w najbardziej uproszczonej formie można przedstawić następująco: jeśli nad kompilatorem pracują trzy zespoły, wówczas efektem będzie kompilator składający się z trzech części. Dlatego jeśli w organizacji panuje wysoki poziom izolacji, nawet Kubernetes, wyłącznik, rozszerzalność API i inne fantazyjne rzeczy w tej organizacji zostaną zorganizowane w taki sam sposób, jak sama organizacja. Ściśle według Conwaya i na przekór wszystkim młodym maniakom.
Rozwiązanie tego problemu było już wielokrotnie opisywane. Istnieją na przykład archetypy organizacyjne opisane przez Fernando Fernandeza. Ta problematyczna architektura, o której właśnie mówiłem, z izolacją, jest architekturą zorientowaną na funkcje. Drugi typ to najgorszy, architektura macierzowa, bałagan dwóch pozostałych. Trzeci to ten, który widać u większości startupów i duże firmy też starają się dorównać temu typowi. Jest to organizacja zorientowana na rynek. Tutaj optymalizujemy, aby osiągnąć najszybszą reakcję na żądania klientów. Nazywa się to czasem organizacją płaską.
Wiele osób opisuje tę strukturę na różne sposoby, podoba mi się to sformułowanie budować/uruchamiać zespoły, w Amazon tak to nazywają dwa zespoły zajmujące się pizzą. W tej strukturze wszystkie osoby typu „I” skupiają się wokół jednej usługi i stopniowo zbliżają się do typu „T”, a przy odpowiednim zarządzaniu mogą nawet stać się „E”. Pierwszym kontrargumentem jest to, że taka konstrukcja zawiera niepotrzebne elementy. Po co potrzebny tester w każdym dziale, skoro można mieć specjalny dział testerów? Na co odpowiadam: dodatkowe koszty w tym przypadku są ceną, za jaką cała organizacja stanie się w przyszłości typem „E”. W tej strukturze tester stopniowo poznaje sieci, architekturę, projektowanie itp. Dzięki temu każdy uczestnik organizacji jest w pełni świadomy wszystkiego, co dzieje się w organizacji. Jeśli chcesz wiedzieć jak ten schemat sprawdza się w przemyśle, przeczytaj .
7. Audytorzy z przesunięciem w lewo: audyt na początku cyklu. Przestrzeganie zasad bezpieczeństwa na wystawie
Dzieje się tak wtedy, gdy Twoje działania nie przechodzą, że tak powiem, testu zapachu. Ludzie, którzy dla ciebie pracują, nie są głupi. Jeśli tak jak w powyższym przykładzie wszędzie ustawili niewielki/żadny wpływ, trwało to trzy lata i nikt nic nie zauważył, to wszyscy doskonale wiedzą, że system nie działa. Albo inny przykład – rada doradcza ds. zmian, której raporty trzeba składać w każdą, powiedzmy, środę. Pracuje tam grupa ludzi (swoją drogą niezbyt dobrze opłacana), która teoretycznie powinna wiedzieć, jak działa system jako całość. W ciągu ostatnich pięciu lat prawdopodobnie zauważyłeś, że nasze systemy są niezwykle złożone. A pięć, sześć osób musi podjąć decyzję o zmianie, której nie dokonały i o której nic nie wiedzą.
Oczywiście to podejście nie działa. Muszę się pozbyć takich rzeczy, ponieważ ci ludzie nie chronią systemu. Decyzję musi podjąć sam zespół, bo zespół musi być za nią odpowiedzialny. W przeciwnym razie dochodzi do paradoksalnej sytuacji, gdy menadżer, który nigdy w życiu nie pisał kodu, mówi programiście, ile czasu powinno zająć napisanie kodu. Jedna firma, z którą współpracowałem, miała 7 różnych tablic, które sprawdzały każdą zmianę, w tym tablicę architektury, kartę produktu itp. Był nawet obowiązkowy okres karencji, chociaż jeden z pracowników powiedział mi, że przez dziesięć lat pracy nikt nigdy nie odrzucił zmiany dokonanej przez tę osobę w tym obowiązkowym okresie.
Należy zapraszać audytorów, aby do nas dołączyli, a nie się ich pozbywać. Powiedz im, że piszesz niezmienne kontenery binarne, które, jeśli przejdą wszystkie testy, pozostaną niezmienne na zawsze. Powiedz im, że masz potok jako kod i wyjaśnij, co to oznacza. Pokaż im następujący schemat: niezmienny plik binarny tylko do odczytu w kontenerze, który pomyślnie przechodzi wszystkie testy podatności; i wtedy nie tylko nikt tego nie dotyka, ale nawet nie dotyka systemu, który tworzy rurociąg, ponieważ on również jest tworzony dynamicznie. Mam klientów, Capital One, którzy używają Vault do tworzenia czegoś na kształt blockchainu. Audytor nie musi pokazywać „przepisów” od Chefa, wystarczy pokazać blockchain, z którego jasno wynika, co stało się z biletem Jira w produkcji i kto jest za to odpowiedzialny.
Według , utworzonej w 2018 r. przez Sonatype, w 2017 r. odnotowano 87 miliardów żądań pobrania OSS.
Straty poniesione w wyniku luk w zabezpieczeniach są zaporowe. Co więcej, liczby, które widzisz powyżej, nie uwzględniają kosztów alternatywnych. Czym w skrócie jest DevSecOps? Od razu powiem, że nie interesuje mnie mówienie o sukcesie tej nazwy. Rzecz w tym, że skoro DevOps odniósł taki sukces, powinniśmy spróbować dodać zabezpieczenia do tego potoku.
Przykład tej sekwencji:
Nie jest to rekomendacja konkretnych produktów, chociaż wszystkie mi się podobają. Przytoczyłem je jako przykład, żeby pokazać, że DevOps, początkowo bazujący na paradygmacie organizacyjnym w przemyśle, pozwala zautomatyzować każdy etap pracy nad produktem.
I nie ma powodu, dla którego nie moglibyśmy przyjąć takiego samego podejścia do bezpieczeństwa.
Łączny
Na zakończenie dam kilka wskazówek dla DevSecOps. Musisz włączyć audytorów w proces tworzenia swoich systemów i poświęcić czas na ich edukację. Trzeba współpracować z audytorami. Następnie musisz stoczyć absolutnie bezlitosną walkę z fałszywymi alarmami. Nawet korzystając z najdroższego narzędzia do skanowania podatności na zagrożenia, możesz wykształcić wśród programistów wyjątkowo złe nawyki, jeśli nie wiesz, jaki jest stosunek sygnału do szumu. Programiści będą przytłoczeni wydarzeniami i po prostu je usuną. Jeśli słyszałeś o historii Equifax, to mniej więcej tak właśnie się tam wydarzyło, gdzie zignorowano najwyższy poziom alertu. Ponadto słabe punkty należy wyjaśnić w sposób wyjaśniający ich wpływ na działalność biznesową. Można na przykład powiedzieć, że jest to ta sama luka, co w historii Equifax. Luki w zabezpieczeniach należy traktować tak samo jak inne problemy z oprogramowaniem, to znaczy należy je uwzględnić w ogólnym procesie DevOps. Musisz z nimi współpracować poprzez Jira, Kanban itp. Programiści nie powinni myśleć, że zrobi to ktoś inny - wręcz przeciwnie, każdy powinien to zrobić. Wreszcie musisz poświęcić energię na szkolenie ludzi.
Przydatne linki
Oto kilka wykładów z konferencji DevOops, które mogą okazać się przydatne:
- Sergey Berdnikov, Artem Kalichkin - Historia sukcesu, czyli „Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik – DevOps w skali: tragedia grecka w trzech aktach (, )
- Aleksander Titow, Cyryl Tołkaczow –
- Tymoteusz Lister –
Zbadać DevOops 2020 Moskwa – jest tam też wiele ciekawych rzeczy.
Źródło: www.habr.com