Pytanie „jak wdrożyć DevOps w swoim zespole” pojawia się od wielu lat, ale nie ma zbyt wielu dobrych materiałów na ten temat. Czasami stajemy się ofiarami reklam nieodpowiedzialnych konsultantów, którzy próbują sprzedać swój czas, niezależnie od tego, jak. Czasami są to niejasne, bardzo ogólne słowa na temat tego, jak statki megakorporacji przemycają się przez bezkres wszechświata. Pojawia się pytanie: co z tego mamy my? Szanowny autorze, czy możesz w jasny sposób przedstawić swoje pomysły w formie listy?
Wszystko to wynika z faktu, że rzeczywistej praktyki i zrozumienia wyników transformacji kultury w firmach jest jak na lekarstwo. Zmiany w kulturze są procesem długofalowym, efekty których nie pojawią się w ciągu tygodnia ani miesiąca. Potrzebujemy kogoś wystarczająco doświadczonego, kto widział, jak przez lata powstawały i upadały firmy.
John Willis jest jednym z ojców DevOps. Ma za sobą dziesiątki lat pracy z ogromną liczbą firm. W ostatnim czasie John zaczął dostrzegać specyficzne wzorce, które występują w pracy z każdą z nich. Wykorzystując te archetypy, John prowadzi firmy na właściwą drogę do transformacji DevOps. Więcej o tych archetypach znajdziecie w tłumaczeniu jego prezentacji z konferencji DevOops 2018.
O prelegencie:
Ponad 35 lat w zarządzaniu IT, uczestniczył w tworzeniu poprzednika OpenCloud w Canonical, brał udział w 10 startupach, z których dwa sprzedał Dellowi i Dockerowi. Obecnie jest wiceprezydentem ds. DevOps i praktyk cyfrowych w SJ Technologies.
Przechodzimy teraz do narracji z perspektywy Johna.
Nazywam się John Willis i łatwiej mnie znaleźć na Twitterze, . Taki sam pseudonim mam na Gmailu i GitHubie. A możecie znaleźć nagrania moich wystąpień oraz prezentacje do nich.
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 wyjaśnić, mówi o czymś swoim. Innym częstym narzekaniem jest to, że DevOps nie działa, chociaż wydaje się, że dyrektorzy robią wszystko zgodnie z wytycznymi. Mówimy o dużych firmach, które mają ponad sto lat. Rozmawiając z nimi, doszedłem do wniosku, że dla wielu problemów lepiej pasują nie zaawansowane technologie, a bardziej niskottechnologiczne rozwiązania. Przez tygodnie po prostu rozmawiałem z ludźmi z różnych działów. To, co widzicie na pierwszym obrazku w poście — to mój ostatni projekt, pokój wyglądał tak po trzech dniach pracy.
Czym jest DevOps?
Rzeczywiście, jeśli zapytasz 10 różnych osób, dadzą ci 10 różnych odpowiedzi. Ale co ciekawe: wszystkie te dziesięć odpowiedzi będzie poprawnych. Nie ma tutaj złej odpowiedzi. Od około 10 lat zajmuję się DevOps, byłem pierwszym Amerykaninem na pierwszym DevOpsDay. Nie powiem, że jestem mądrzejszy od wszystkich, którzy zajmują się DevOps, ale trudno znaleźć kogoś, kto poświęcił na to tyle samo sił. Uważam, że DevOps powstaje wtedy, gdy łączą się kapitał ludzki i technologia. Często zapominamy o ludzkim wymiarze, chociaż dużo mówimy o różnego rodzaju kulturach.
Obecnie posiadamy wiele danych, pięć lat badań akademickich, weryfikacja teorii jest już ustanowiona w skali przemysłowej. Te badania mówią nam, że jeśli w kulturze organizacyjnej połączy się pewne wzorce zachowań, można osiągnąć przyspieszenie do 2000 razy. Temu przyspieszeniu odpowiada podobna poprawa odporności. To ilościowy pomiar tego, jakie korzyści może przynieść DevOps każdej firmie. Kilka lat temu opowiadałem o DevOps dyrektorowi generalnemu firmy z listy Fortune 5000. Gdy przygotowywałem się do prezentacji, bardzo się stresowałem, ponieważ musiałem w 5 minut przedstawić swoje wieloletnie doświadczenie.
W rezultacie podałem następujące definicję DevOps: to zestaw praktyk i wzorców, które pozwalają przekształcić kapitał ludzki w wysoko wydajny kapitał organizacyjny. Przykład — sposób, w jaki Toyota działa przez ostatnie 50 lub 60 lat.
(Schemes like this are not provided as reference material, but as illustrations. Their content will differ for each new company. Nevertheless, the image can be viewed separately and enlarged)
One of the most successful practices is value stream mapping. Several good books have been written about this, with the most successful author being Karen Martin. However, over the past year, I've concluded that even this approach is too high-tech. It certainly has many advantages, which I have used extensively. But when the CEO asks you why his company can't switch to new systems, it's still too early to talk about value stream mapping. There are many significantly more fundamental questions that need to be answered first.
I feel that a mistake many of my colleagues make is that they simply give the company a five-point guide and then return after six months to see what happened. Even a good scheme like value stream mapping has, so to speak, blind spots. After hundreds of interviews with directors from various companies, I've developed a certain pattern that allows me to break the problem down into components, and we will now discuss each of these components in order. Before applying any technological solutions, I use this pattern, and as a result, all my walls end up covered with diagrams. Recently, I worked with a mutual fund, and I ended up with 100-150 such diagrams.
A bad culture eats good approaches for breakfast
The main idea is this: no Lean, Agile, SAFE, or DevOps will help if the organization's culture is poor. It's like diving to depth without a diving suit or operating without an X-ray. In other words, paraphrasing Drucker and Deming: a poor organizational culture will consume any good system and not choke on it.
To address this main problem, the following steps need to be taken:
- Make All Work Visible: it is necessary to make all work visible. Not in the sense that it must necessarily be displayed on some screen, but in the sense that it should be observable.
- Consolidate Work Management Systems: Należy skonsolidować systemy zarządzania. W problemie „plemiennej” wiedzy i wiedzy instytucjonalnej w 9 na 10 przypadków wąskim gardłem są ludzie. W książce problem był jednocześnie związany z jednym człowiekiem, Brentem, przez którego projekt miał trzy lata opóźnienia. Na takich „Brentów” natykam się wszędzie. Aby rozwiązać te wąskie gardła, stosuję dwa punkty z naszego wykazu.
- Metodologia Teorii Ograniczeń: teoria ograniczeń.
- Zarządzanie współpracą: hakowanie współpracy.
- Toyota Kata (): o Toyota Kata nie będę dużo mówił. Jeśli to interesujące, na moim GitHubie niemal na każdy z tych tematów.
- Organizacja zorientowana na rynek: organizacja zorientowana na rynek.
- Audyty wczesnego etapu: audyt na wczesnych etapach cyklu.
Zaczynam pracę z organizacją w bardzo prosty sposób: idę do firmy i rozmawiam z pracownikami. Jak widać, żadnej nowoczesnej technologii. Wszystko, co potrzebne, to coś, na czym można pisać. Zbieram kilka zespołów w jednym pomieszczeniu i analizuję to, co mówią, z perspektywy moich 7 archetypów. A potem daję im marker i proszę, aby spisali na tablicy wszystko, co do tej pory mówili na głos. Zazwyczaj na takich spotkaniach jest jedna osoba, która wszystko zapisuje, i w najlepszym przypadku udaje jej się zanotować 10% dyskusji. Moja metoda pozwala podnieść ten wskaźnik do około 40%.
(Tę ilustrację można osobno )
Moje podejście opiera się na pracy Williama Schneidera (William Schneider, ). W centrum podejścia leży myśl, że każdą organizację można rozłożyć na cztery kwadraty. Ta schemat jest zwykle wynikiem pracy z setkami innych schematów, które pojawiają się podczas analizy organizacji. Załóżmy, że mamy organizację z wysokim poziomem kontroli, ale z niską kompetencją. To niezwykle niepożądana sytuacja: gdy wszyscy chodzą w rytmie, ale nikt nie wie, co należy robić.
Nieco lepsza opcja z wysokim poziomem zarówno kontroli, jak i kompetencji. Jeśli taka firma przynosi zyski, to być może DevOps nie jest jej potrzebny. Najciekawiej jest pracować z firmą, która ma wysoki poziom kontroli, niską kompetencję i współpracę, ale jednocześnie wysoką kulturę (cultivation). Oznacza to, że w firmie jest wielu ludzi, którzy lubią tam pracować, a rotacja pracowników jest niska.
(Tę ilustrację można osobno )
Wydaje mi się, że metody z sztywno określonymi wytycznymi ostatecznie utrudniają osiągnięcie prawdy. W szczególności, w mapowaniu strumienia wartości jest wiele zasad dotyczących tego, jak należy strukturalizować informacje. Na wczesnych etapach pracy, o których mówię, te zasady nikomu nie są potrzebne. Gdy osoba z markerem w ręku opisuje na tablicy rzeczywistą sytuację w firmie — to najlepszy sposób, aby zrozumieć stan rzeczy. Tego rodzaju informacje nie docierają do dyrektorów. W tym momencie głupotą jest przerywanie i mówienie, że ktoś niewłaściwie narysował jakąś strzałkę. Na tym etapie lepiej stosować proste zasady, na przykład: wielopoziomową abstrakcję można stworzyć, używając po prostu kolorowych markerów.
Powtarzam, żadnych wysokich technologii. Czarnym markerem przedstawiana jest obiektywna rzeczywistość, jak wszystko działa. Czerwonym markerem ludzie zaznaczają, co dokładnie im nie odpowiada w obecnym stanie rzeczy. Ważne jest, że to oni to piszą, a nie ja. Kiedy po spotkaniu idę do dyrektora ds. technologii informacyjnej, nie przedkładam listy 10 rzeczy, które trzeba poprawić. Dążę do znalezienia powiązań między tym, co mówią ludzie z firmy, a istniejącymi sprawdzonymi wzorcami. W końcu, niebieskim markerem proponowane są możliwe rozwiązania problemu.
(Tę ilustrację można osobno )
Przykład takiego podejścia jest teraz przedstawiony powyżej. Na początku tego roku pracowałem z jednym bankiem. Pracownicy z działu bezpieczeństwa byli przekonani, że nie mogą uczestniczyć w przeglądach wymagań i projektowania (design and requirement reviews).
(Tę ilustrację można osobno )
A potem rozmawialiśmy z ludźmi z innych działów i okazało się, że około 8 lat temu programiści oprogramowania wyeliminowali pracowników bezpieczeństwa, ponieważ spowalniali pracę. A potem to przekształciło się w zakaz, który był postrzegany jako fakt. Chociaż tak naprawdę żadnego zakazu nie było.
Nasze spotkanie miało niezwykle skomplikowany przebieg: przez około trzy godziny pięć różnych zespołów nie mogło mi wyjaśnić, co się dzieje między kodem a kompilacją. A to wydawała się najprostsza rzecz. Większość konsultantów DevOps zakłada z góry, że to już jest wszystkim znane.
Potem osoba odpowiedzialna za zarządzanie IT (IT governance), milczała przez cztery godziny, nagle się ożywiła, gdy dotarliśmy do jej tematu, i zajęła nas jeszcze na dość długi czas. Na koniec zapytałem ją, co myśli o spotkaniu, i nigdy nie zapomnę jej odpowiedzi. Powiedziała: 'Dawniej myślałem, że w naszym banku są tylko dwa sposoby dostarczania oprogramowania, a teraz wiem, że jest ich całych pięć, a o trzech nawet nie miałem pojęcia.'
(Tę ilustrację można osobno )
Ostatnie spotkanie w tym banku odbyło się z zespołem zajmującym się oprogramowaniem dla inwestycji. To właśnie z nim okazało się, że lepiej pisać schematy markerem na kartce niż na tablicy, a nawet lepiej niż na smartboardzie.
Zdjęcia, które widzicie, przedstawiają to, jak wyglądała sala konferencyjna hotelu w czwarty dzień naszego spotkania. I te schematy wykorzystaliśmy do poszukiwania wzorców, czyli archetypów.
Tak więc, zadaję pytania pracownikom, oni zapisują odpowiedzi markerami trzech kolorów (czarnym, czerwonym i niebieskim). Analizuję ich odpowiedzi pod kątem archetypów. Teraz porozmawiajmy o wszystkich archetypach w kolejności.
1. Make All Work Visible: Uczynić pracę widoczną
W większości firm, z którymi pracuję, występuje bardzo wysoki procent niezaplanowanej pracy. Na przykład, kiedy jeden pracownik przychodzi do drugiego i po prostu prosi o zrobienie czegoś. W dużych organizacjach może to być aż 60% niezaplanowanej pracy. Aż do 40% pracy nie jest dokumentowane w żaden sposób. Gdyby to był Boeing, to nigdy więcej bym nie wsiadł do ich samolotu. Jeśli dokumentowana jest tylko połowa pracy, to nie wiadomo, czy ta praca jest wykonywana poprawnie. Wszystkie inne metody okazują się bezużyteczne — nie ma sensu próbować cokolwiek zautomatyzować, ponieważ znane 50% może być najbardziej zorganizowaną i klarowną częścią pracy, która nie przyniesie dużych rezultatów, a to, co najgorsze, znajduje się w tej niewidocznej połowie. W przypadku braku dokumentacji niemożliwe jest znalezienie różnego rodzaju hacków i ukrytej pracy, a także identyfikacja wąskich gardeł, tych „Brentów”, o których już wspomniałem. Jest świetna książka autorstwa Dominiki DeGrandis. . Odkrywa pięć różnych „uchwyty czasu” (thieves of time):
- Zbyt dużo pracy w toku (WIP)
- Nieznane zależności
- Niezaplanowana praca
- Sprzeczne priorytety
- Zaniedbana praca
To bardzo cenny analiz, a książka jest wspaniała, ale wszystkie te porady są bezużyteczne, jeśli widoczne są tylko 50% danych. Metody zaproponowane przez Dominikę można stosować, jeśli osiągnięto dokładność powyżej 90%. Mówię o sytuacjach, gdy przełożony daje pracownikowi 15-minutowe zadanie, a on zajmuje się tym przez trzy dni; ale przełożony w rzeczywistości nie wie, że ten pracownik 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 zwolnienie z tego powodu, a on spotyka innego bohatera, który przedstawiany jest jako swoisty Sokrates. Pomaga mu zrozumieć, co dokładnie poszło nie tak. Okazuje się, że w firmie jest jeden sysadmin, który nazywa się Brent, a cała praca w taki czy inny sposób przechodzi przez niego. Na jednym z spotkań jeden z podwładnych pyta: dlaczego każde półgodzinne zadanie zajmuje tydzień? W odpowiedzi pada bardzo uproszczone przedstawienie teorii kolejek i prawa Little'a, z którego wynika, że przy 90%-owym obciążeniu każda godzina pracy zajmuje 9 godzin. Każde zadanie musi być przekazywane siedmiu innym osobom, dlatego ta godzina zamienia się w 63 godziny, 7 razy 9. Mówię o tym, ponieważ aby wykorzystać prawo Little'a lub jakąkolwiek bardziej skomplikowaną teorię kolejek, trzeba przynajmniej mieć dane.
Dlatego kiedy mówię o widoczności, nie mam na myśli, że wszystko powinno być na ekranie, ale to, że należy mieć przynajmniej dane. Kiedy już są, często okazuje się, że istnieje bardzo duża ilość niezaplanowanej pracy, która z jakiegoś powodu trafia do Brenta, chociaż nie ma takiej potrzeby. A Brent to świetny facet, nigdy nie powie „nie”, ale nie informuje nikogo, jak wykonuje swoją pracę.
Gdy praca jest widoczna, można starannie klasyfikować dane (właśnie tym zajmuje się Dominika na zdjęciu), można stosować abstrakcję pięciu wycieków czasu i automatyzować.
2. Konsolidacja systemów zarządzania pracą: Zarządzanie zadaniami
Archetypy, o których mówię, tworzą pewnego rodzaju piramidę. Jeśli pierwszy zostanie wykonany poprawnie, drugi stanowi już swoistą nadbudowę. Wiele z nich nie działa dla startupów, należy je mieć na uwadze w przypadku dużych firm, takich jak te, które trafiają na listę Fortune 5000. W ostatniej firmie, w której pracowałem, było 10 systemów śledzenia błędów (system ticketowy). W jednej drużynie był Remedy, inna stworzyła swój własny system, trzecia korzystała z Jira, a niektórzy radzili sobie tylko za pomocą e-maila. Ta sama kwestia pojawia się, jeśli w firmie jest 30 różnych procesów, ale nie mam czasu, aby omówić wszystkie podobne przypadki.
Rozmawiam z ludźmi o tym, jak właściwie tworzone są zgłoszenia, co się z nimi dzieje dalej i jak je omijają. Najciekawsze jest to, że ludzie na naszych spotkaniach mówią dość szczerze. Zapytałem, ile osób przypisuje "minimalny / brak wpływu" do zgłoszeń, którym faktycznie powinno się przypisać "duży wpływ". Okazało się, że tak robi prawie każdy. Nie zajmuję się donoszeniem i staram się nie ujawniać ludzi. Kiedy ktoś szczerze mi się przyznaje, nie ujawniam tej osoby. Ale gdy prawie wszyscy omijają system, oznacza to, że cała bezpieczeństwo jest w istocie tylko dekoracją. Dlatego na podstawie tych danych nie można wyciągać żadnych wniosków.
Aby rozwiązać problem ze zgłoszeniami, należy wybrać jeden główny system. Jeśli korzystasz z Jira, niech będzie tylko Jira. Jeśli istnieje jakaś alternatywa, niech będzie tylko ona. Chodzi o to, aby traktować zgłoszenia jako kolejny etap procesu rozwoju. Każda czynność powinna mieć zgłoszenie, które przechodzi przez proces rozwoju. Zgłoszenia są wysyłane do zespołu, który umieszcza je na tablicy storyboard, a następnie ponosi odpowiedzialność za nie.
Dotyczy to wszystkich działów, w tym infrastrukturalnego i operacyjnego. W takim przypadku można stworzyć jakiekolwiek prawdopodobne przedstawienie sytuacji. Kiedy ten proces jest ustalony, okazuje się, że łatwo można ustalić, kto odpowiada za każdą aplikację. Ponieważ teraz otrzymujemy nie 50%, a 98% nowych usług. Jeśli ten podstawowy proces działa, dokładność wzrasta w całym systemie.
Pipeline usług
To dotyczy to ponownie tylko dużych korporacji. Jeśli jesteś nową firmą w nowej dziedzinie — zakasać rękawy i pracować nad swoim Travis CI lub CircleCI. Jeśli chodzi o firmy z Fortune 5000, godny uwagi jest przypadek, który miał miejsce w banku, w którym pracowałem. Otrzymali oni wizytę od Google, które pokazało im wykresy ze starymi systemami IBM. Ludzie z Google z niedowierzaniem zapytali — a gdzie jest kod źródłowy? A żadnego kodu źródłowego nie ma, nie ma nawet GUI. To jest rzeczywistość, w której muszą funkcjonować dużej organizacje: 40-letnie zapisy bankowe na starym mainframe'ie. Jeden z moich klientów używa kontenerów Kubernetes z wzorcami Circuit Breaker, plus Chaos Monkey, wszystko to dla aplikacji KeyBank. Ale te kontenery ostatecznie łączą się z aplikacją napisaną w COBOL-u.
Ludzie z Google byli głęboko przekonani, że rozwiążą wszystkie problemy mojego klienta, a potem zaczęli zadawać pytania: co to jest IBM datapipe? Odpowiadają: to jest konektor. Do czego się łączy? Z systemem Sperry. A co to jest? I tak dalej. Na pierwszy rzut oka wydaje się: co tu może być w DevOps? Ale w rzeczywistości to jest możliwe. Istnieją systemy dostarczania, które pozwalają przekazać proces roboczy zespołom zajmującym się dostarczaniem.
3. Teoria ograniczeń: Theory of Constraints
Przejdźmy do trzeciego archetypu: wiedzy instytucjonalnej / „plemiennej”. Zwykle w każdej organizacji jest kilka osób, które wiedzą wszystko i wszystkim kierują. To ci, którzy najdłużej pracują w organizacji i znają wszystkie skróty.
Gdy to ujawnia się na diagramie, specjalnie zaznaczam takich ludzi markerem: na przykład okazuje się, że jakiś Lou jest obecny na wszystkich spotkaniach. I dla mnie jest jasne: to lokalny Brent. Gdy dyrektor IT wybiera między mną w t-shircie i trampkach a facetem w garniturze z IBM, wybierają mnie, ponieważ mogę opowiedzieć dyrektorowi o rzeczach, których ten drugi facet nie powie i o których dyrektorowi może być nieprzyjemnie słyszeć. Mówię im, że w ich firmie jest wąskie miejsce, to ktoś o imieniu Fred i ktoś o imieniu Lou. To wąskie miejsce musi zostać rozwiązane, ich wiedza musi być w jakiś sposób wydobyta.
Aby rozwiązać tego rodzaju problem, mogę na przykład zaproponować użycie Slacka. Przenikliwy dyrektor zapyta — dlaczego? Zazwyczaj w takich sytuacjach konsultanci DevOps odpowiadają: bo wszyscy tak robią. Jeśli dyrektor jest naprawdę bystry, powie: i co z tego. I na tym dialog się kończy. A odpowiadam na to: ponieważ w firmie są cztery wąskie gardła: Fred, Lou, Suzy i Jane. Aby zinstytucjonalizować ich wiedzę, należy najpierw wprowadzić Slacka. Wszystkie wasze wiki to kompletna bzdura, ponieważ nikt nie wie o ich istnieniu. Jeśli zespół inżynierów zajmuje się rozwojem zewnętrznym i wewnętrznym, wszyscy muszą wiedzieć, że mogą zwrócić się do zespołu rozwoju zewnętrznego lub zespołu infrastruktury z pytaniami. Wtedy prawdopodobnie Lou lub Fred znajdą czas, aby spojrzeć na wiki. A potem ktoś może zapytać na Slacku, dlaczego nie działa, powiedzmy, krok 5. I wtedy Lou lub Fred poprawią instrukcję na wiki. Jeśli ten proces zostanie ustalony, wiele rzeczy samo się ułoży.
W tym moja główna myśl: aby polecać jakieś nowoczesne technologie, najpierw trzeba uporządkować fundament pod nie, a można to zrobić jedynie opisanymi przed chwilą niskotechnologicznymi rozwiązaniami. Jeśli zaczniesz od nowoczesnych technologii i nie wyjaśnisz, po co są potrzebne, to zazwyczaj nic dobrego z tego nie wynika. Jeden z naszych klientów korzysta z Azure ML, bardzo taniego i prostego rozwiązania. W około 30% przypadków odpowiedzi udziela już sama maszyna ucząca się. A stworzyli tę rzecz operatorzy, którzy nie zajmowali się data science, statystyką ani matematyką. To jest wymowne. Koszt takiego rozwiązania jest minimalny.
4. Haki współpracy: Collaboration hacks
Czwarty archetyp dotyczy walki z izolacją. Większość ludzi już to wie: izolacja rodzi wrogość. Jeśli każdy dział jest na swoim piętrze, a ludzie stykają się ze sobą jedynie w windzie, wrogość między nimi powstaje bardzo łatwo. A jeśli przeciwnie, ludzie znajdują się w jednym pomieszczeniu, wrogość natychmiast znika. Gdy ktoś rzuca ogólne oskarżenie, na przykład, że taki a taki interfejs nigdy nie działa — nie ma nic prostszego, jak to oskarżenie zdekonstrukcjonować. Programiści, którzy napisali interfejs, wystarczy, że zaczną zadawać konkretne pytania, a wkrótce okaże się, że na przykład użytkownik po prostu niewłaściwie korzystał z narzędzia.
Jest wiele sposobów na przezwyciężenie izolacji. Kiedyś poproszono mnie o konsultacje dla banku w Australii, odmówiłem, ponieważ mam dwoje dzieci i żonę. Wszystko, czym mogłem im pomóc, to polecenie im opowiadania wizualnego (graphical storytelling). To metoda, która rzeczywiście działa. Innym ciekawym sposobem są spotkania w formacie lean coffee. W dużej organizacji to doskonała opcja na rozpowszechnianie wiedzy. Ponadto można organizować wewnętrzne devopsdays, hackathony i inne tego typu wydarzenia.
5. Coaching Kata
Jak już ostrzegałem na samym początku, dziś nie będę o tym opowiadał. Jeśli ktoś jest zainteresowany, może zobaczyć .
Jest też dobra prezentacja na ten temat od Mike'a Rothera:
6. Market Oriented: organizacja zorientowana na rynek
Są tutaj różne problemy. Na przykład ludzie typy „I”, „T” i „E”. Ludzie „I” to ci, którzy zajmują się tylko jedną rzeczą. Zazwyczaj istnieją oni w organizacjach z izolowanymi jednostkami. „T” to osoba, która dobrze zna coś jednego, ale również odnosi sukcesy w innych dziedzinach. „E” lub nawet „grzebień” to osoba, która ma wiele umiejętności.
Tutaj działa prawo Conwaya (), które w maksymalnie uproszczonej formie można wyrazić tak: jeśli trzy zespoły pracują nad kompilatorem, to ostatecznie powstanie kompilator składający się z trzech części. Dlatego jeśli w organizacji występuje wysoki poziom izolacji, nawet Kubernetes, Circuit breaker, API extensibility i inne modne rzeczy w tej organizacji będą zorganizowane tak, jak sama organizacja. Ściśle według Conwaya i na złość wszystkim wam, młodym geekom.
Rozwiązanie tego problemu było opisywane wielokrotnie. Na przykład, istnieją archetypy organizacyjne opisane przez Fernando Fernandeza. Architektura problemowa, o której właśnie mówiłem, z izolacją — to architektura zorientowana na funkcje. Drugi typ — najgorszy, to architektura macierzowa, tam mamy miszmasz z dwóch innych. Trzeci typ — to to, co obserwuje się w większości startupów, a duże firmy również próbują przyjąć ten typ. To organizacja zorientowana na rynek. Tutaj odbywa się optymalizacja, aby uzyskać najszybszą reakcję na prośby klientów. Czasami nazywa się to płaską organizacją.
Wiele osób opisuje tę strukturę na różne sposoby, osobiście lubię sformułowanie build/run teams, w Amazonie nazywa się to two pizza teams. W tej strukturze wszyscy ludzie typu „I” grupują się wokół jednego serwisu, a stopniowo stają się bliżsi typowi „T”, a jeśli zorganizowany jest odpowiedni zarząd, mogą stać się nawet „E”. Pierwszym kontrargumentem jest tutaj to, że w takiej strukturze są zbędne elementy. Po co tester w każdym dziale, skoro można mieć specjalny dział testerów? Na co odpowiadam: zbędne wydatki w tym przypadku to cena za to, aby w przyszłości cała organizacja stała się typu „E”. W takiej strukturze tester stopniowo poznaje sieci, architekturę, projektowanie itd. W końcu każdy uczestnik organizacji staje się całkowicie świadomy wszystkiego, co dzieje się w organizacji. Jeśli chcesz wiedzieć, jak ten schemat działa w przemyśle, przeczytaj .
7. Shift-left auditors: audyt na wczesnych etapach cyklu. Przestrzeganie zasad bezpieczeństwa na pokaz.
To jest, gdy twoje działania nie przechodzą testu zapachowego. Ludzie, którzy na ciebie pracują, nie są głupi. Jeśli, tak jak w powyższym przykładzie, wszędzie wystawiali minor/no impact, to trwało to trzy lata i nikt niczego nie zauważył, to wszyscy doskonale wiedzą, że system nie działa. Albo inny przykład — rada doradcza ds. zmian (change advisory board), do której co środę należy składać raporty. Pracuje tam grupa ludzi (nota bene, nie za dobrze opłacanych), którzy teoretycznie powinni wiedzieć, jak działa system jako całość. A przez ostatnie pięć lat zauważyłeś zapewne, że nasze systemy są szalenie złożone. Pięć lub sześć osób powinno podjąć decyzję w sprawie zmiany, której same nie wprowadziły i o której nie mają pojęcia.
Oczywiście, takie podejście nie działa. Muszę się pozbywać takich rzeczy, ponieważ ci ludzie nie chronią systemu. Decyzję powinna podejmować sama drużyna, ponieważ to drużyna powinna być za to odpowiedzialna. W przeciwnym razie powstaje paradoksalna sytuacja, w której menedżer, który nigdy w życiu nie pisał kodu, mówi programiście, ile czasu powinno zająć napisanie kodu. W jednej firmie, w której pracowałem, było 7 różnych rad, które rozpatrywały każdą zmianę, w tym radę ds. architektury, produktów itp. Istniał nawet obowiązkowy okres oczekiwania, chociaż jeden pracownik powiedział mi, że przez dziesięć lat pracy nikt nigdy w tym obowiązkowym okresie nie odrzucił zmian wprowadzonych przez tę osobę.
Audytorów należy zapraszać do współpracy, a nie się ich pozbywać. Powiedz im, że piszesz niemutowalne kontenery binarne, które, jeśli przejdą wszystkie testy, pozostają niezmienne na zawsze. Powiedz im, że masz pipeline as code i wyjaśnij, co to znaczy. Pokaż im następujący schemat: niemutowalny binarny plik tylko do odczytu w kontenerze, który przeszedł wszystkie testy pod kątem podatności; a potem nikt nie dotyka go — nawet system, który tworzy pipeline, ponieważ również on jest tworzony dynamicznie. Mam klientów, takich jak Capital One, którzy przy pomocy Vault tworzą coś na kształt blockchaina. Audytorowi nie trzeba pokazywać „przepisów” z Chefa, wystarczy pokazać blockchain, z którego jasno wynika, co się stało z ticketem Jira w produkcji i kto za niego odpowiada.
Zgodnie z , stworzony w 2018 roku Sonatype, w 2017 roku odnotowano 87 miliardów zapytań o pobranie OSS.
Straty poniesione z powodu podatności okazują się nadmiernie wysokie. Przy czym liczby, które widzisz powyżej, nie obejmują kosztów alternatywnych. W dwóch zdaniach o tym, czym jest DevSecOps. Od razu chcę powiedzieć, że nie interesują mnie dyskusje na temat tego, jak szczęśliwie wybrane jest to nazewnictwo. Chodzi o to, że skoro DevOps osiągnęły duży sukces, warto spróbować dodać do tego pipeline'u bezpieczeństwo.
Przykład takiej sekwencji:
To nie jest rekomendacja określonych produktów, chociaż wszystkie mi się podobają. Przywołuję je jako przykład, aby pokazać, że DevOps, oparty pierwotnie na paradygmacie organizacji w przemyśle, umożliwia automatyzację każdego etapu pracy nad produktem.
Nie ma żadnego powodu, dla którego nie moglibyśmy zastosować tego samego podejścia do bezpieczeństwa.
Podsumowanie
Na zakończenie chciałbym przedstawić kilka porad dla DevSecOps. Należy zaangażować audytorów w proces tworzenia waszych systemów oraz poświęcić czas na ich edukację. Ważna jest współpraca z audytorami. Następnie, należy bezwzględnie walczyć z fałszywymi alarmami. Nawet najdroższe narzędzie do skanowania podatności może prowadzić do szkodliwych nawyków wśród programistów, jeśli nie rozumie się stosunku sygnału do szumu. Programiści będą przytłoczeni zdarzeniami i po prostu je zignorują. Jeśli słyszeliście historię z Equifax, to właśnie to się stało, tam zignorowano sygnał najwyższego poziomu niebezpieczeństwa. Ponadto, podatności powinny być przedstawiane w sposób, który jasno pokazuje, jak wpływają na biznes. Na przykład, można powiedzieć, że to ta sama podatność, co w przypadku Equifax. Zagadnienia związane z bezpieczeństwem należy traktować jak inne problemy z oprogramowaniem, czyli należy je włączyć w ogólny proces DevOps. Należy z nimi pracować za pośrednictwem Jira, Kanban itp. Programiści nie powinni myśleć, że zajmie się tym ktoś inny — wręcz przeciwnie, wszyscy powinni się tym zajmować. Na koniec, należy poświęcić wysiłki na edukację ludzi.
Przydatne linki
Oto kilka prezentacji z konferencji DevOops, które mogą okazać się dla Ciebie przydatne:
- Siergiej Berdnikow, Artiom Kaliczkin — Historia sukcesu, czyli „Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igołnik — DevOps w skali: grecka tragedia w trzech aktach (, )
- Aleksandr Titow, Kirill Tolkaczow —
- Timothy Lister —
Zajrzyj do DevOops 2020 Moskwa — tam również znajdziesz wiele interesujących rzeczy.
Źródło: habr.com
