Założyciel i dyrektor „Otomato Software”, jeden z inicjatorów i instruktorów pierwszej w Izraelu certyfikacji DevOps, Anton Weiss, mówił w zeszłym roku o teorii chaosu oraz głównych zasadach inżynierii chaosu, a także wyjaśnił, jak powinna wyglądać idealna organizacja DevOps przyszłości.
Przygotowaliśmy tekstową wersję referatu.
Dzień dobry!
DevOpsDays w Moskwie po raz drugi, ja po raz drugi na tej scenie, wielu z was po raz drugi w tej sali. Co to oznacza? To oznacza, że ruch DevOps w Rosji rośnie, mnoży się, a co najważniejsze, to oznacza, że nadszedł czas, aby porozmawiać o tym, czym jest DevOps w 2018 roku.
Podnieście ręce ci, którzy uważają, że w 2018 roku DevOps to już zawód? Są tacy. Czy są w sali inżynierowie DevOps, którzy w opisie stanowiska mają napisane „inżynier DevOps”? Czy są w sali menedżerowie DevOps? Tych nie ma. Architekci DevOps? Też nie. Trochę mało. Czy naprawdę nikt nie ma w opisie stanowiska, że jest inżynierem DevOps?
Czyli większość z was myśli, że to antywzorzec? Że takiego zawodu nie powinno być? Możemy myśleć, co chcemy, a podczas gdy my myślimy, przemysł z wielką pompą posuwa się do przodu w rytmie DevOps.
Kto słyszał o nowym temacie, który nazywa się DevDevOps? To nowa metoda, która pozwala zapewnić skuteczną współpracę między programistami a devopsami. A tak wcale nie jest nowa. Jeśli sądzić po Twitterze, to już 4 lata temu zaczęto o tym rozmawiać. I do tej pory zainteresowanie tym rośnie, to znaczy problem istnieje. Problem trzeba rozwiązać.
Jesteśmy osobami twórczymi, tak łatwo się nie uspokajamy. Mówimy: DevOps to za mało ogólne słowo, brakuje tam wielu różnych interesujących elementów. I idziemy do naszych tajnych laboratorium i zaczynamy tworzyć ciekawe mutacje: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika żelazna, prawda? Mamy system dostawy, który nie jest funkcjonalny, mamy systemy niestabilne, a użytkownicy są niezadowoleni, nie nadążamy z wydawaniem oprogramowania na czas, nie mieścimy się w budżecie. Jak zamierzamy to wszystko rozwiązać? Wymyślimy nowe słowo! Będzie się kończyć na „Ops”, i problem rozwiązany.
Tak nazywam to podejście — „Ops, i problem rozwiązany”.
Wszystko to schodzi na dalszy plan, gdy przypominamy sobie, po co to wszystko wymyśliliśmy. Wymyśliliśmy ten cały DevOps, aby uczynić dostarczanie oprogramowania i naszą pracę w tym procesie jak najbardziej bezproblemową, bezbolesną, efektywną, a przede wszystkim przyjemną.
DevOps wyrósł z bólu. I mamy dość cierpienia. Aby to wszystko się wydarzyło, opieramy się na wiecznie zielonych praktykach: efektywna współpraca, praktyki przepływu, a co najważniejsze, myślenie systemowe, ponieważ bez niego żaden DevOps nie działa.
Czym jest system?
A skoro już mówimy o myśleniu systemowym, przypomnijmy sobie, czym jest system.
Jeśli jesteś rewolucjonistą-hakerem, to dla Ciebie system to jednoznaczne zło. To chmura, która wisi nad Tobą i zmusza Cię do robienia rzeczy, których nie chcesz robić.
Z punktu widzenia myślenia systemowego, system to pewna całość składająca się z części. W tym sensie każdy z nas to system. Organizacje, w których pracujemy, to systemy. A to, co budujemy, nazywa się systemem.
Wszystko to jest częścią jednej wielkiej socjotechnologicznej systemu. I tylko jeśli zrozumiemy, jak ten socjotechnologiczny system działa razem, tylko wtedy będziemy mogli coś w tym zakresie naprawdę zoptymalizować.
Z punktu widzenia myślenia systemowego, system ma różne ciekawe właściwości. Po pierwsze, składa się z części, co oznacza, że jego zachowanie zależy od zachowania tych części. Przy tym wszystkie jego części są również współzależne. Okazuje się, że im więcej system ma części, tym trudniej zrozumieć lub przewidzieć jego zachowanie.
Z punktu widzenia zachowania, tutaj jest jeszcze jeden ciekawy fakt. System może robić coś takiego, czego żadna z jego oddzielnych części zrobić nie może.
Jak mówił doktor Russell Ackoff (jeden z pionierów myślenia systemowego), można to łatwo udowodnić za pomocą myślowego eksperymentu. Na przykład, kto w sali potrafi pisać kod? Wiele rąk, i to jest normalne, ponieważ to jedno z podstawowych wymagań w naszej profesji. Potrafisz pisać, a Twoje ręce oddzielnie od Ciebie mogą pisać kod? Są tacy ludzie, którzy powiedzą: „To nie moje ręce piszą kod, to mój mózg pisze kod”. A mózg może oddzielnie od Ciebie pisać kod? Cóż, najprawdopodobniej nie.
Mózg to niezwykła maszyna, a my nie wiemy nawet 10% o tym, jak naprawdę działa. Nie może funkcjonować oddzielnie od systemu, którym jest nasze ciało. Łatwo to udowodnić: otwórz swoją czaszkę, wyjmij stamtąd mózg, połóż go przed komputerem i niech spróbuje napisać coś prostego. Na przykład "Hello, world" w Pythonie.
Jeśli system może wykonać coś, czego żadna z jego części osobno nie potrafi, oznacza to, że jego zachowanie nie jest determinowane przez zachowanie jego części. A czym więc jest determinowane? Jest determinowane interakcjami między tymi częściami. A zatem, im więcej części, tym bardziej skomplikowane interakcje, tym trudniej zrozumieć i przewidzieć zachowanie systemu. To sprawia, że taki system jest chaotyczny, ponieważ jakakolwiek, nawet najdrobniejsza, niewidoczna gołym okiem zmiana w którejkolwiek z części systemu może prowadzić do całkowicie nieprzewidywalnych rezultatów.
Ta wrażliwość na warunki początkowe została po raz pierwszy odkryta i zbadana przez amerykańskiego meteorologa Eda Lorenza. Z czasem zyskała nazwę "efekt motyla" i doprowadziła do rozwoju ruchu naukowego, który nazywany jest "teorią chaosu". Teoria ta stała się jednym z głównych przesunięć paradygmatu w nauce XX wieku.
Teoria chaosu
Ludzie, którzy zajmują się badaniem chaosu, nazywają siebie chaotykami.
Właściwą przyczyną tego wystąpienia jest to, że pracując z złożonymi systemami rozproszonymi i dużymi międzynarodowymi organizacjami, w pewnym momencie zrozumiałem, że to właśnie tym się czuję. Jestem chaotyk. To w ogóle sprytny sposób powiedzenia: "Nie rozumiem, co się tutaj dzieje i nie wiem, co z tym zrobić."
Myślę, że wielu z was również często tak się czuje, zatem także wy jesteście chaotykami. Zapraszam was do gildii chaotyków. Systemy, które będziemy badać, drodzy koledzy chaotycy, nazywają się "złożonymi systemami adaptacyjnymi".
Czym jest adaptacyjność? Adaptacyjność oznacza, że indywidualne i zbiorowe zachowanie części w takiej adaptacyjnej systemie zmienia się i samoorganizuje, reagując na zdarzenia lub ciągi mikroskalowych zdarzeń w systemie. Innymi słowy, system dostosowuje się do zmian poprzez samoorganizację. Ta zdolność do samoorganizacji opiera się na dobrowolnej, całkowicie zdecentralizowanej współpracy wolnych autonomicznych agentów.
Kolejną interesującą cechą takich systemów jest to, że są one swobodnie skalowalne. Co niewątpliwie powinno nas, jako inżynierów chaosu, interesować. Jeśli powiedzieliśmy, że zachowanie złożonego systemu jest określone interakcją jego części, to co powinno nas interesować? Interakcja.
Są jeszcze dwa interesujące wnioski.
Po pierwsze, rozumiemy, że nie można uprościć złożonego systemu poprzez uproszczenie jego części. Po drugie, jedynym sposobem na uproszczenie złożonego systemu jest uproszczenie interakcji między jego częściami.
Jak wchodzimy w interakcję? Wszyscy jesteśmy częściami dużego systemu informacyjnego, który nazywa się społeczeństwem ludzkim. Interagujemy poprzez wspólny język, jeśli go posiadamy, jeśli go odnajdujemy.
Ale język sam w sobie jest złożonym systemem adaptacyjnym. W związku z tym, aby interakcja była bardziej efektywna i prosta, musimy stworzyć pewne protokoły. To znaczy jakąś sekwencję symboli i działań, które uczynią wymianę informacji między nami prostszą, bardziej przewidywalną, bardziej zrozumiałą.
Chcę powiedzieć, że tendencje do komplikacji, adaptacyjności, decentralizacji i chaotyczności są dostrzegane wszędzie. Zarówno w tych systemach, które budujemy, jak i w tych systemach, których częścią jesteśmy.
I aby nie być gołosłownym, spójrzmy na to, jak zmieniają się te systemy, które tworzymy.
Rozumiesz, że czekałeś na to słowo. Jesteśmy na konferencji DevOps, dzisiaj to słowo zabrzmi gdzieś sto tysięcy razy, a potem przyśni nam się w nocy.
Mikroserwisy to pierwsza architektura oprogramowania, która powstała w odpowiedzi na praktyki DevOps, mająca na celu uczynienie naszych systemów bardziej elastycznymi, skalowalnymi i zapewniającymi ciągłe dostarczanie. W jaki sposób to robi? Dzięki zmniejszeniu objętości usług, ograniczeniu granic problemów, które te usługi obsługują, oraz skróceniu czasu dostarczania. Oznacza to, że zmniejszamy, upraszczamy części systemu, zwiększamy ich liczbę, co nieuchronnie zwiększa złożoność interakcji między tymi częściami, a zatem pojawiają się nowe problemy, które musimy rozwiązywać.
Mikroserwisy to jeszcze nie koniec; tak naprawdę, mikroserwisy to już wczorajszy dzień, ponieważ nadchodzi Serverless. Wszystkie serwery się spaliły, nie ma serwerów, nie ma systemów operacyjnych, tylko czysty kod wykonawczy. Konfiguracje osobno, stany osobno, wszystko zarządzane wydarzeniami. Piękno, czystość, cisza, brak wydarzeń, nic się nie dzieje, pełny porządek.
Gdzie tkwi złożoność? Złożoność, rzecz jasna, w interakcjach. Ile jedna funkcja może zrobić sama? Jak współdziała z innymi funkcjami? Kolejki wiadomości, bazy danych, load balancery. Jak odtworzyć jakieś zdarzenie, gdy nastąpiła awaria? Masa pytań i niewiele odpowiedzi.
Mikroserwisy i Serverless to wszystko, co my, komputerowi hipsterzy, nazywamy Cloud Native. To wszystko dotyczy chmury. Ale chmura z natury też jest ograniczona pod względem skalowalności. Przywykliśmy myśleć o niej jak o rozproszonej systemie. W rzeczywistości, gdzie znajdują się serwery dostawców chmurowych? W centrach danych. Oznacza to, że mamy do czynienia z pewnym scentralizowanym, bardzo ograniczonym, rozproszonym modelem.
Dziś rozumiemy, że Internet rzeczy to już nie tylko głośne słowa; według skromnych prognoz, w ciągu najbliższych pięciu do dziesięciu lat czeka nas miliardy urządzeń podłączonych do internetu. Ogromna ilość użytecznych i bezużytecznych danych, które będą spływać do chmury i być z niej pobierane.
Chmura tego nie wytrzyma, dlatego coraz częściej mówimy o tym, co nazywa się „obliczeniami na krawędzi”. Albo podoba mi się wspaniała definicja „fog computing”. Jest ona owiana mistyką romantyzmu i tajemniczości.
Mgliste obliczenia. Mowa o tym, że chmury to centralne skupiska wody, pary, lodu, kamieni. A mgła to krople wody, które są rozproszone wokół nas w atmosferze.
W mglistym paradygmacie większość pracy wykonywana jest przez te krople zupełnie autonomicznie lub w współpracy z innymi kroplami. Zwracają się do chmury tylko wtedy, gdy rzeczywiście jest to bardzo pilne.
Innymi słowy, znowu decentralizacja, autonomiczność, no i oczywiście wielu z was już rozumie, dokąd to wszystko zmierza, bo nie można mówić o decentralizacji i nie wspomnieć o blockchainie.
Są ci, którzy wierzą, to są ci, którzy zainwestowali w kryptowaluty. Są ci, którzy wierzą, ale się boją, jak ja, na przykład. A są i tacy, którzy nie wierzą. Można mieć różne opinie na ten temat. Jest technologia, nowa, niezrozumiała rzecz, są problemy. Jak każda nowa technologia stawia więcej pytań, niż daje odpowiedzi.
Hype wokół blockchaina jest zrozumiały. Nawet jeśli odrzucimy złotą gorączkę, sama technologia obiecuje wspaniałą przyszłość: więcej wolności, więcej autonomii, rozproszony globalny zaufanie. Czego tu nie chcieć?
W związku z tym coraz więcej inżynierów na całym świecie zaczyna rozwijać zdecentralizowane aplikacje. I to jest siła, której nie można zignorować, po prostu mówiąc: „Aaaa, blockchain to tylko źle zaimplementowana rozproszona baza danych”. Lub jak sceptycy lubią mówić: „Nie ma żadnych prawdziwych zastosowań dla blockchaina”. Jeśli się nad tym zastanowić, 150 lat temu mówili to samo o elektryczności. I właściwie w czymś mieli rację, ponieważ to, co elektryczność czyni możliwym dzisiaj, w XIX wieku było całkowicie niemożliwe.
A tak przy okazji, kto wie, co to za logo na ekranie? To Hyperledger. To projekt rozwijany pod auspicjami The Linux Foundation, obejmujący zestaw technologii blockchainowych. To naprawdę siła naszej społeczności otwartego kodu.
Inżynieria chaosu
Otóż system, który rozwijamy, staje się coraz bardziej złożony, coraz bardziej chaotyczny, coraz bardziej adaptacyjny. Netflix to pionierzy systemów mikroserwisowych. Byli jednymi z pierwszych, którzy to zrozumieli, opracowali zestaw narzędzi, który nazwali Simian Army, z których najsłynniejszy to . Zdefiniował to, co stało się znane jako .
Zresztą, podczas pracy nad raportem przetłumaczyliśmy ten tekst na język rosyjski, więc zapraszam do , czytajcie, komentujcie, krytykujcie.
W skrócie, zasady inżynierii chaosu mówią o tym, że skomplikowane systemy rozproszone z definicji są nieprzewidywalne i zawierają błędy. Błędy są nieuniknione, co oznacza, że musimy je zaakceptować i pracować z tymi systemami zupełnie inaczej.
Musimy sami starać się wprowadzać te błędy do naszych systemów produkcyjnych, aby testować naszą zdolność do adaptacji, samoorganizacji i przetrwania tych systemów.
I to zmienia wszystko. Nie tylko to, jak wdrażamy system do produkcji, ale także, jak je rozwijamy i testujemy. Nie ma żadnego procesu stabilizacji, zamrażania kodu, wręcz przeciwnie, jest ciągły proces dezorganizacji. Staramy się zabić system i zobaczyć, co przetrwa.
Protokoły Integracji Systemów Rozproszonych
Odpowiednio, wymaga to od naszych systemów, aby również się zmieniły. Aby stały się bardziej odporne, potrzebują nowych protokołów interakcji między swoimi częściami. Tak, aby te części mogły się komunikować i osiągnąć jakąś formę samozorganizowania. I pojawiają się różne nowe narzędzia, nowe protokoły, które nazywam „protokolami interakcji systemów rozproszonych“.
O czym mówię? Przede wszystkim o projekcie . Pewna próba stworzenia wspólnego protokołu śledzenia rozproszonego, który jest niezbędnym narzędziem do debugowania złożonych systemów rozproszonych.
Dalej — . Mówimy, że nie możemy przewidzieć, co się stanie z systemem, więc musimy zwiększyć jego obserwowalność. Opentracing należy do rodziny narzędzi, które umożliwiają obserwowalność naszych systemów. Ale obserwowalność jest nam potrzebna, aby określić, czy system zachowuje się tak, jak oczekujemy, czy nie. Jak określić oczekiwane zachowanie? Poprzez definiowanie w niej pewnej polityki, pewnego zestawu zasad. Projekt Open Policy Agent zajmuje się definiowaniem tego zestawu zasad w szerokim zakresie: od dostępu po alokację zasobów.
Jak już wspomnieliśmy, nasze systemy stają się coraz bardziej zorientowane na zdarzenia. Serverless to doskonały przykład systemów zorientowanych na zdarzenia. Abyśmy mogli przekazywać zdarzenia między systemami i je śledzić, potrzebujemy wspólnego języka, wspólnego protokołu, aby móc rozmawiać o zdarzeniach, jak je sobie przekazujemy. Tym zajmuje się projekt o nazwie .
Ciągły strumień zmian, który przepływa przez nasze systemy, nieustannie je destabilizując, to ciągły strumień artefaktów programowych. Abyśmy mogli utrzymać ten stały strumień zmian, potrzebujemy wspólnego protokołu, dzięki któremu będziemy mogli rozmawiać o tym, czym jest artefakt programowy, jak jest weryfikowany i jakie testy przeszedł. Tym zajmuje się projekt o nazwie . To znaczy wspólny protokół metadanych artefaktów programowych.
I wreszcie, jeśli chcemy, aby nasze systemy były całkowicie samodzielne, adaptacyjne i samoorganizujące się, musimy im dać prawo do samoidentyfikacji. Projekt o nazwie tym się właśnie zajmuje. To również projekt pod egidą Cloud Native Computing Foundation.
Wszystkie te projekty są młode, wszystkie potrzebują naszej miłości, naszej weryfikacji. To wszystko jest otwartym kodem, naszym testowaniem, naszą implementacją. Pokazują nam, w jakim kierunku zmierza technologia.
Ale DevOps nigdy nie był przede wszystkim o technologii, zawsze był przede wszystkim o współpracy między ludźmi. I jeśli chcemy, aby systemy, które tworzymy, się zmieniły, musimy się zmienić. W rzeczywistości zmieniamy się już, nie mamy szczególnie wyboru.
Istnieje wspaniała książka brytyjskiej pisarki Rachel Botsman, w której pisze o ewolucji zaufania w historii ludzkości. Mówi, że początkowo, w prymitywnych społeczeństwach, zaufanie było lokalne, to znaczy ufaliśmy tylko tym, których znamy osobiście.
Następnie był bardzo długi okres — ciemny czas, kiedy zaufanie było scentralizowane, gdy zaczęliśmy ufać ludziom, których nie znamy, na podstawie tego, że należymy do tej samej instytucji społecznej lub rządowej.
I oto, co widzimy w naszym współczesnym świecie: zaufanie staje się coraz bardziej rozproszone i zdecentralizowane, a opiera się na wolności przepływu informacji, na dostępności informacji.
Jeśli się nad tym zastanowić, to właśnie tę dostępność, która umożliwia to zaufanie, my realizujemy. To oznacza, że muszą się zmieniać zarówno nasze metody współpracy, jak i sposób, w jaki to robimy, ponieważ scentralizowane hierarchiczne organizacje IT starego typu przestają działać. Zaczynają wygasać.
Podstawy organizacji DevOps
Idealna organizacja DevOps przyszłości to zdecentralizowany, adaptacyjny system składający się z autonomicznych zespołów, z których każdy składa się z niezależnych jednostek. Zespoły te są rozsiane po całym świecie, skutecznie współpracują ze sobą, korzystając z komunikacji asynchronicznej oraz wysoko przejrzystych protokołów wymiany informacji. Bardzo piękne, prawda? Bardzo piękna przyszłość.
Oczywiście, to wszystko jest niemożliwe bez zmian kulturowych. Musimy mieć transformacyjne przywództwo, osobistą odpowiedzialność, wewnętrzną motywację.
To jest podstawa organizacji DevOps: przejrzystość informacji, komunikacja asynchroniczna, transformacyjne przywództwo, decentralizacja.
Wypalenie zawodowe
Systemy, których częścią jesteśmy i te, które budujemy, stają się coraz bardziej chaotyczne, a nam, ludziom, trudno pogodzić się z tą myślą, trudno zrezygnować z iluzji kontroli. Staramy się nadal je kontrolować, a często prowadzi to do wypalenia zawodowego. Mówię to z własnego doświadczenia, również się sparzyłem, również jestem ofiarą nieprzewidzianych awarii w produkcji.
Wypalenie zawodowe występuje wtedy, gdy próbujemy kontrolować to, co z zasady nie poddaje się kontroli. Kiedy doświadczamy wypalenia, wszystko traci sens, ponieważ tracimy chęć do tworzenia czegoś nowego, przyjmujemy postawę defensywną i zaczynamy bronić tego, co jest.
Zawód inżyniera, jak często lubię sobie przypominać, to przede wszystkim zawód kreatywny. Jeśli tracimy chęć do tworzenia, to zamieniamy się w popiół, zamieniamy się w żar. Wypalają się ludzie, wypalają się całe organizacje.
Moim zdaniem, tylko akceptacja twórczej siły chaosu, tylko budowanie współpracy na jego zasadach — to, co pomoże nam nie utracić tego, co dobre w naszym zawodzie.
Czego wam życzę: kochać swoją pracę, kochać to, co robimy. Ten świat żyje informacją, mamy zaszczyt go zasilać. Więc uczmy się chaosu, bądźmy chaosologami, przynośmy wartość, twórzmy coś nowego, a problemy, jak już się przekonaliśmy, są nieuniknione i kiedy się pojawią, powiemy po prostu „Ups!“, a problem zostanie rozwiązany.
Co oprócz Chaos Monkey?
Tak naprawdę wszystkie te narzędzia są bardzo młode. Netflix tworzył narzędzia dla siebie. Budujcie narzędzia dla siebie. Czytajcie zasady inżynierii chaosu i stosujcie się do tych zasad, a nie próbujcie szukać innych narzędzi, które ktoś inny już stworzył.
Starajcie się zrozumieć, jak wasze systemy się łamią i zaczynajcie je łamać oraz obserwować, jak znoszą uderzenia. To jest najważniejsze. A narzędzia można poszukać. Jest wiele projektów.
Nie do końca zrozumiałem moment, w którym mówiliście, że nie można upraszczać systemu poprzez upraszczanie jego komponentów, a od razu przeszliście do mikrousług, które właśnie upraszczają system poprzez upraszczanie samych komponentów, a jednocześnie komplikują interakcje. To zasadniczo dwie sprzeczne ze sobą części.
Zgadza się, mikrousługi to bardzo kontrowersyjny temat. Tak naprawdę uproszczenie części zwiększa elastyczność. Czym mikrousługi nam dają? Dają nam elastyczność i szybkość, ale na pewno nie dają prostoty. Zwiększają złożoność.
Czyli w filozofii DevOps mikrousługi to wcale nie jest takie błogosławieństwo?
Każde dobro ma swoją ciemną stronę. Istnieje dobro: zwiększa elastyczność, daje nam możliwość szybszych zmian, ale zwiększa złożoność i w związku z tym kruchość całego systemu.
Na co w końcu kłaść większy nacisk: na uproszczenie interakcji czy na uproszczenie części?
Nacisk zdecydowanie kładziony jest na uproszczenie interakcji, ponieważ jeśli spojrzymy na to z perspektywy naszej współpracy, to przede wszystkim należy skupić się na uproszczeniu interakcji, a nie na uproszczeniu pracy każdego z nas z osobna. Uproszczenie pracy to przekształcanie nas w roboty. W McDonald's działa to dobrze, gdy masz jasne instrukcje: tutaj połóż burgera, tutaj dodaj sos. W naszej kreatywnej pracy to zupełnie nie działa.
Czy to prawda, że wszystko, co powiedziałeś, żyje w świecie bez konkurencji, gdzie chaos jest dobroczynny, a wewnątrz tego chaosu nie ma sprzeczności, nikt nikogo nie chce zjeść ani zabić? Jak konkurencja i DevOps powinny funkcjonować?
To zależy, o jakiej konkurencji mówimy. O konkurencji w miejscu pracy czy o konkurencji między firmami?
O konkurencji usług, które istnieją, ponieważ usługi to nie kilka firm. Tworzymy nowy typ środowiska informacyjnego, a każde środowisko nie może istnieć bez konkurencji. Wszędzie występuje konkurencja.
Podobnie jak Netflix, bierzemy ich jako model ról. Dlaczego to wymyślili? Ponieważ musieli być konkurencyjni. Ta elastyczność i szybkość działania są dokładnie tym konkurencyjnym wymogiem, który wnosi chaos do naszych systemów. Chaos nie jest czymś, co świadomie tworzymy, ponieważ tego chcemy, to coś, co następuje w wyniku wymagań świata. Musimy się po prostu dostosować. Chaos jest więc rezultatem konkurencji.
Czy to oznacza, że chaos to brak celów? A może cele, których nie chcemy widzieć? Jesteśmy w jakiejś bańce i nie rozumiemy celów innych. Konkurencja, w rzeczywistości, wynika z tego, że mamy jasno określone cele i wiemy, dokąd zmierzamy w każdym następnym momencie. W tym, moim zdaniem, tkwi istota DevOps.
Też spojrzenie na sprawę. Myślę, że naszym celem jest jeden: przetrwać i robić to z
największą przyjemnością. A konkurencyjny cel każdej organizacji jest taki sam. Przetrwanie często odbywa się w konkurencyjnej walce, tu już nic nie zrobisz.
W tym roku konferencja odbędzie się 7 grudnia w „Technopoli”. Zgłoszenia na referaty przyjmujemy do 11 listopada. do nas, jeśli chcecie wystąpić.
Rejestracja dla uczestników jest otwarta, bilet kosztuje 7000 rubli. Dołącz do nas!
Źródło: habr.com
