Anton Weiss, założyciel i dyrektor Otomato Software, jeden z inicjatorów i instruktorów pierwszej certyfikacji DevOps w Izraelu, wypowiadał się na ubiegłorocznej konferencji o teorii chaosu i głównych zasadach inżynierii chaosu, a także wyjaśnił, jak działa idealna organizacja przyszłości DevOps.
Przygotowaliśmy wersję tekstową raportu.
Dzień dobry!
DevOpsDays w Moskwie drugi rok z rzędu, to mój drugi raz na tej scenie, wielu z Was jest na tej sali po raz drugi. Co to znaczy? Oznacza to, że ruch DevOps w Rosji rośnie, mnoży się, a co najważniejsze oznacza, że nadszedł czas, aby porozmawiać o tym, czym jest DevOps w 2018 roku.
Rękę do góry, kto uważa, że DevOps to już zawód w 2018 roku? Są takie. Czy na sali są inżynierowie DevOps, których opis stanowiska brzmi „Inżynier DevOps”? Czy są na sali menadżerowie DevOps? Nie ma czegoś takiego. Architekci DevOps? Również nie. Niewystarczająco. Czy to prawda, że nikt nie mówi, że jest inżynierem DevOps?
Zatem większość z Was uważa, że jest to anty-wzorzec? Że taki zawód nie powinien istnieć? Możemy myśleć, co chcemy, ale gdy myślimy, branża uroczyście posuwa się do przodu przy dźwiękach trąbki DevOps.
Kto słyszał o nowym temacie o nazwie DevDevOps? To nowa technika, która pozwala na efektywną współpracę pomiędzy programistami i devopsami. I nie takie nowe. Sądząc po Twitterze, zaczęli o tym rozmawiać już 4 lata temu. I do tej pory zainteresowanie tym rośnie i rośnie, czyli jest problem. Problem należy rozwiązać.
Jesteśmy kreatywnymi ludźmi, nie odpoczywamy spokojnie. Mówimy: DevOps nie jest wystarczająco obszernym słowem, brakuje mu jeszcze najróżniejszych, ciekawych elementów. I idziemy do naszych tajnych laboratoriów i zaczynamy produkować ciekawe mutacje: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika jest żelazna, prawda? Nasz system dostaw nie działa, nasze systemy są niestabilne, a nasi użytkownicy są niezadowoleni, nie mamy czasu na terminowe wdrożenie oprogramowania, nie mieścimy się w budżecie. Jak to wszystko rozwiążemy? Wymyślimy nowe słowo! Zakończy się „Ops” i problem zostanie rozwiązany.
Dlatego nazywam to podejście „Ops, a problem został rozwiązany”.
Wszystko to schodzi na dalszy plan, jeśli przypomnimy sobie, dlaczego to wszystko wymyśliliśmy. Wymyśliliśmy cały ten DevOps, aby dostarczanie oprogramowania i nasza własna praca w tym procesie były jak najbardziej nieskrępowane, bezbolesne, wydajne i, co najważniejsze, przyjemne.
DevOps wyrósł z bólu. I jesteśmy zmęczeni cierpieniem. A żeby to wszystko się udało, stawiamy na praktyki evergreeny: efektywną współpracę, praktyki przepływu i co najważniejsze myślenie systemowe, bo bez tego żaden DevOps nie działa.
Czym jest system?
A jeśli już mówimy o myśleniu systemowym, przypomnijmy sobie, czym jest system.
Jeśli jesteś rewolucyjnym hakerem, to dla ciebie system jest wyraźnie zły. 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 całość składająca się z części. W tym sensie każdy z nas jest systemem. Organizacje, w których pracujemy, to systemy. A to, co ty i ja budujemy, nazywa się systemem.
Wszystko to jest częścią jednego dużego systemu społeczno-technologicznego. I tylko wtedy, gdy zrozumiemy, jak ten system społeczno-technologiczny ze sobą współpracuje, tylko wtedy będziemy w stanie naprawdę coś zoptymalizować w tej kwestii.
Z punktu widzenia myślenia systemowego system ma różne interesujące właściwości. Po pierwsze, składa się z części, co oznacza, że jego zachowanie zależy od zachowania części. Co więcej, wszystkie jego części są również współzależne. Okazuje się, że im więcej części ma system, tym trudniej jest zrozumieć lub przewidzieć jego zachowanie.
Z behawioralnego punktu widzenia jest jeszcze jeden interesujący fakt. System może zrobić coś, czego nie potrafi żadna z jego poszczególnych części.
Jak powiedział dr Russell Ackoff (jeden z twórców myślenia systemowego), można to dość łatwo udowodnić za pomocą eksperymentu myślowego. Na przykład, kto na sali wie, jak pisać kod? Rąk jest dużo i jest to normalne, ponieważ jest to jeden z głównych wymagań w naszym zawodzie. Czy umiesz pisać, ale czy Twoje ręce potrafią pisać kod oddzielnie od Ciebie? Są ludzie, którzy powiedzą: „To nie moje ręce piszą kod, to mój mózg pisze kod”. Czy Twój mózg może pisać kod niezależnie od Ciebie? Cóż, prawdopodobnie nie.
Mózg to niesamowita maszyna, nie wiemy nawet w 10%, jak w nim działa, ale nie może funkcjonować w oderwaniu od układu, jakim jest nasze ciało. A to łatwo udowodnić: otwórz czaszkę, wyjmij mózg, postaw przed komputer, niech spróbuje napisać coś prostego. Na przykład „Hello, world” w Pythonie.
Jeśli system może zrobić coś, czego żadna z jego części nie jest w stanie zrobić osobno, oznacza to, że jego zachowanie nie jest zdeterminowane zachowaniem jego części. Od czego więc to zależy? Decyduje o tym interakcja pomiędzy tymi częściami. Odpowiednio, im więcej części, tym bardziej złożone interakcje, tym trudniej jest zrozumieć i przewidzieć zachowanie systemu. A to powoduje, że taki system jest chaotyczny, bo każda, nawet najmniejsza, niewidoczna zmiana w jakiejkolwiek części systemu może prowadzić do zupełnie nieprzewidywalnych rezultatów.
Tę wrażliwość na warunki początkowe po raz pierwszy odkrył i zbadał amerykański meteorolog Ed Lorenz. Później nazwano to „efektem motyla” i doprowadziło do rozwoju ruchu myśli naukowej zwanego „teorią chaosu”. Teoria ta stała się jedną z głównych zmian paradygmatu w nauce XX wieku.
Teoria chaosu
Ludzie badający chaos nazywają siebie chaosologami.
Właściwie powodem powstania tego raportu było to, że pracując ze złożonymi systemami rozproszonymi i dużymi organizacjami międzynarodowymi, w pewnym momencie zdałem sobie sprawę, że właśnie tak się czuję. Jestem chaosologiem. Jest to w zasadzie 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, więc jesteście także chaosologami. Zapraszam Cię do gildii chaosologów. Systemy, które wy i ja, drodzy koledzy chaosolodzy, będziemy badać, nazywane są „złożonymi systemami adaptacyjnymi”.
Co to jest zdolność adaptacyjna? Adaptowalność oznacza, że indywidualne i zbiorowe zachowanie części takiego systemu adaptacyjnego zmienia się i samoorganizuje, reagując na zdarzenia lub łańcuchy mikrozdarzeń w systemie. Oznacza to, że system dostosowuje się do zmian poprzez samoorganizację. A ta zdolność do samoorganizacji opiera się na dobrowolnej, całkowicie zdecentralizowanej współpracy wolnych, autonomicznych agentów.
Kolejną interesującą właściwością takich systemów jest to, że są one dowolnie skalowalne. Co niewątpliwie powinno nas zainteresować, jako chaosologów-inżynierów. Jeśli więc powiemy, że zachowanie złożonego systemu zależy od interakcji jego części, to czym powinniśmy się interesować? Interakcja.
Istnieją jeszcze dwa interesujące znaleziska.
Po pierwsze, rozumiemy, że złożonego systemu nie można uprościć poprzez uproszczenie jego części. Po drugie, jedynym sposobem uproszczenia złożonego systemu jest uproszczenie interakcji pomiędzy jego częściami.
Jak wchodzimy w interakcję? Ty i ja jesteśmy częściami dużego systemu informacyjnego zwanego społeczeństwem ludzkim. Komunikujemy się poprzez wspólny język, jeśli go mamy i jeśli go znajdziemy.
Ale sam język jest złożonym systemem adaptacyjnym. W związku z tym, aby interakcja była wydajniejsza i prostsza, musimy stworzyć pewnego rodzaju protokoły. Czyli jakaś sekwencja symboli i działań, które sprawią, że wymiana informacji między nami będzie prostsza, bardziej przewidywalna, bardziej zrozumiała.
Chcę powiedzieć, że tendencje do złożoności, do adaptacji, do decentralizacji, do chaosu można prześledzić we wszystkim. Oraz w systemach, które ty i ja budujemy, i w tych systemach, których jesteśmy częścią.
I żeby nie było bezpodstawnie, przyjrzyjmy się, jak zmieniają się systemy, które tworzymy.
Rozumiem, że czekałeś na to słowo. Jesteśmy na konferencji DevOps, dzisiaj to słowo usłyszymy jakieś sto tysięcy razy, a potem będziemy o nim śnić po nocach.
Mikrousługi to pierwsza architektura oprogramowania, która pojawiła się w reakcji na praktyki DevOps, a która ma na celu uczynienie naszych systemów bardziej elastycznymi, bardziej skalowalnymi i zapewniającymi ciągłe dostarczanie. Jak ona to robi? Poprzez zmniejszenie wolumenu usług, zmniejszenie zakresu problemów, które te usługi przetwarzają, skrócenie czasu dostawy. Oznacza to, że zmniejszamy i upraszczamy części systemu, zwiększamy ich liczbę, w związku z czym niezmiennie wzrasta złożoność interakcji między tymi częściami, to znaczy pojawiają się nowe problemy, które musimy rozwiązać.
Mikroserwisy to nie koniec, mikroserwisy w ogóle są już wczoraj, bo nadchodzi Serverless. Wszystkie serwery spłonęły, żadnych serwerów, żadnych systemów operacyjnych, tylko czysty kod wykonywalny. Konfiguracje są oddzielne, stany są oddzielne, wszystko jest kontrolowane przez zdarzenia. Piękno, czystość, cisza, żadnych wydarzeń, nic się nie dzieje, pełen porządek.
Gdzie jest złożoność? Trudność polega oczywiście na interakcjach. Ile jedna funkcja może zrobić samodzielnie? Jak to współdziała z innymi funkcjami? Kolejki wiadomości, bazy danych, balansery. Jak odtworzyć jakieś zdarzenie, gdy wystąpiła awaria? Wiele pytań i mało odpowiedzi.
Mikrousługi i rozwiązania bezserwerowe to coś, co my, maniacy hipsterzy, nazywamy Cloud Native. Wszystko zależy od chmury. Jednak chmura ma również z natury ograniczoną skalowalność. Przyzwyczailiśmy się myśleć o tym jak o systemie rozproszonym. Gdzie właściwie znajdują się serwery dostawców usług w chmurze? W centrach danych. Oznacza to, że mamy tutaj do czynienia ze scentralizowanym, bardzo ograniczonym i rozproszonym modelem.
Dziś rozumiemy, że Internet Rzeczy to już nie tylko wielkie słowa, że nawet według skromnych przewidywań w ciągu najbliższych pięciu, dziesięciu lat czekają na nas miliardy urządzeń podłączonych do Internetu. Ogromna ilość przydatnych i bezużytecznych danych, które zostaną scalone w chmurę i przesłane z chmury.
Chmura nie będzie trwała, dlatego coraz częściej mówimy o czymś, co nazywa się przetwarzaniem brzegowym. Podoba mi się też wspaniała definicja „przetwarzania mgły”. Jest owiana mistycyzmem romantyzmu i tajemniczości.
Obliczenia mgły. Chodzi o to, że chmury to scentralizowane skupiska wody, pary, lodu i kamieni. A mgła to kropelki wody rozproszone wokół nas w atmosferze.
W paradygmacie mgły większość pracy wykonują te kropelki całkowicie autonomicznie lub we współpracy z innymi kropelkami. I zwracają się do chmury tylko wtedy, gdy naprawdę są pod presją.
To znaczy znowu decentralizacja, autonomia i oczywiście wielu z Was już rozumie, dokąd to wszystko zmierza, ponieważ nie można mówić o decentralizacji bez wspomnienia o blockchainie.
Są tacy, którzy wierzą, to ci, którzy zainwestowali w kryptowalutę. Są tacy, którzy wierzą, ale się boją, jak na przykład ja. I są tacy, którzy nie wierzą. Tutaj możesz traktować inaczej. Jest technologia, nowa nieznana sprawa, są problemy. Jak każda nowa technologia, rodzi więcej pytań niż odpowiedzi.
Szum wokół blockchaina jest zrozumiały. Pomijając gorączkę złota, sama technologia niesie ze sobą niezwykłe obietnice dotyczące lepszej przyszłości: większej wolności, większej autonomii i rozproszonego globalnego zaufania. Czego nie chcieć?
W związku z tym coraz więcej inżynierów na całym świecie zaczyna opracowywać zdecentralizowane aplikacje. I jest to siła, której nie można odrzucić, mówiąc po prostu: „Ach, blockchain to po prostu słabo zaimplementowana rozproszona baza danych”. Lub, jak lubią mawiać sceptycy: „Nie ma prawdziwych zastosowań dla blockchain”. Jeśli się nad tym zastanowić, 150 lat temu to samo mówiono o elektryczności. I w pewnym sensie mieli nawet rację, ponieważ to, co dzisiaj umożliwia elektryczność, w XIX wieku w żaden sposób nie było możliwe.
Swoją drogą, kto wie, jakie logo widnieje na ekranie? To jest Hyperledger. Jest to projekt rozwijany pod patronatem The Linux Foundation i obejmujący zestaw technologii blockchain. To jest naprawdę siła naszej społeczności open source.
Inżynieria Chaosu
Zatem system, który rozwijamy, staje się coraz bardziej złożony, coraz bardziej chaotyczny i coraz bardziej adaptacyjny. Netflix jest pionierem systemów mikrousług. Byli jednymi z pierwszych, którzy to zrozumieli i opracowali zestaw narzędzi, który nazwali Armią Simian, z których najbardziej znanym był . Zdefiniował to, co stało się znane jako .
Nawiasem mówiąc, w trakcie pracy nad raportem przetłumaczyliśmy nawet ten tekst na język rosyjski, więc przejdź do , czytaj, komentuj, karć.
Krótko mówiąc, zasady inżynierii chaosu mówią, co następuje. Złożone systemy rozproszone są z natury nieprzewidywalne i z natury pełne błędów. Błędy są nieuniknione, co oznacza, że musimy się z nimi pogodzić i pracować z tymi systemami w zupełnie inny sposób.
Sami musimy spróbować wprowadzić te błędy do naszych systemów produkcyjnych, aby przetestować nasze systemy pod kątem tej samej zdolności adaptacyjnej, tej właśnie zdolności do samoorganizacji i przetrwania.
A to zmienia wszystko. Nie tylko to, jak wprowadzamy systemy do produkcji, ale także to, jak je rozwijamy, jak je testujemy. Nie ma procesu stabilizacji czy zamrożenia kodu, wręcz przeciwnie, istnieje ciągły proces destabilizacji. Próbujemy zabić system i zadbać o to, aby przetrwał.
Protokoły integracji systemów rozproszonych
W związku z tym wymaga to jakiejś zmiany naszych systemów. Aby stały się bardziej stabilne, potrzebują nowych protokołów interakcji między ich częściami. Aby te części mogły się zgodzić i dojść do pewnego rodzaju samoorganizacji. Powstają także wszelkiego rodzaju nowe narzędzia, nowe protokoły, które nazywam „protokołami interakcji systemów rozproszonych”.
O czym mówię? Po pierwsze, projekt . Niektórzy próbują stworzyć ogólny protokół śledzenia rozproszonego, który jest absolutnie niezbędnym narzędziem do debugowania złożonych systemów rozproszonych.
Dalej - . Mówimy, że nie możemy przewidzieć, co stanie się z systemem, to znaczy musimy zwiększyć jego obserwowalność, obserwowalność. Opentracing należy do rodziny narzędzi zapewniających obserwowalność naszych systemów. Potrzebujemy jednak obserwowalności, aby określić, czy system zachowuje się tak, jak tego oczekujemy, czy nie. Jak definiujemy oczekiwane zachowanie? Poprzez zdefiniowanie jakiejś polityki, jakiegoś zestawu zasad. Projekt Open Policy Agent pracuje nad zdefiniowaniem tego zestawu reguł w całym spektrum, od dostępu po alokację zasobów.
Jak powiedzieliśmy, nasze systemy w coraz większym stopniu są sterowane zdarzeniami. Serverless to świetny przykład systemów sterowanych zdarzeniami. Abyśmy mogli przesyłać zdarzenia między systemami i je śledzić, potrzebujemy wspólnego języka, jakiegoś wspólnego protokołu, w jaki sposób mówimy o zdarzeniach i jak je między sobą przekazujemy. Tak się nazywa projekt .
Ciągły strumień zmian, który zalewa nasze systemy, stale je destabilizując, to ciągły strumień artefaktów oprogramowania. Abyśmy mogli utrzymać ten ciągły przepływ zmian, potrzebujemy jakiegoś wspólnego protokołu, dzięki któremu będziemy mogli porozmawiać o tym, czym jest artefakt oprogramowania, w jaki sposób jest testowany i jaką weryfikację przeszedł. Tak się nazywa projekt . Oznacza to, że jest to wspólny protokół metadanych dla artefaktów oprogramowania.
I wreszcie, jeśli chcemy, aby nasze systemy były całkowicie niezależne, adaptacyjne i samoorganizujące się, musimy dać im prawo do samoidentyfikacji. Projekt tzw On właśnie to robi. To także projekt objęty patronatem Cloud Native Computing Foundation.
Wszystkie te projekty są młode, wszystkie potrzebują naszej miłości, naszego uznania. To wszystko jest open source, nasze testy, nasza implementacja. Pokazują nam, dokąd zmierza technologia.
Ale DevOps nigdy nie skupiał się przede wszystkim na technologii, zawsze dotyczył współpracy między ludźmi. I odpowiednio, jeśli chcemy, aby rozwijane przez nas systemy uległy zmianie, sami musimy się zmienić. Tak naprawdę i tak się zmieniamy, nie mamy wielkiego wyboru.
Jest coś wspaniałego Brytyjska pisarka Rachel Botsman, w której pisze o ewolucji zaufania na przestrzeni dziejów ludzkości. Mówi, że początkowo w społeczeństwach prymitywnych zaufanie było lokalne, to znaczy ufaliśmy tylko tym, których znaliśmy osobiście.
Potem był bardzo długi okres – mroczny czas, kiedy zaufanie się scentralizowało, kiedy zaczęliśmy ufać osobom, których nie znamy na podstawie tego, że należymy do tej samej instytucji publicznej czy państwowej.
I to właśnie widzimy we współczesnym świecie: zaufanie staje się coraz bardziej rozproszone i zdecentralizowane, a opiera się na swobodzie 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, właśnie wdrażamy. Oznacza to, że zarówno sposób, w jaki współpracujemy, jak i sposób, w jaki to robimy, musi się zmienić, ponieważ stare, scentralizowane, hierarchiczne organizacje IT już nie działają. Zaczynają wymierać.
Podstawy organizacji DevOps
Idealna organizacja DevOps przyszłości to zdecentralizowany, adaptacyjny system złożony z autonomicznych zespołów, z których każdy składa się z autonomicznych osób. Zespoły te są rozproszone po całym świecie i efektywnie współpracują ze sobą, wykorzystując komunikację asynchroniczną, wykorzystując wysoce przejrzyste protokoły komunikacyjne. Bardzo piękne, prawda? Bardzo piękna przyszłość.
Oczywiście nic z tego nie jest możliwe bez zmian kulturowych. Musimy mieć przywództwo transformacyjne, osobistą odpowiedzialność i wewnętrzną motywację.
To jest podstawa organizacji DevOps: przejrzystość informacji, komunikacja asynchroniczna, przywództwo transformacyjne, decentralizacja.
Burnout
Systemy, których jesteśmy częścią i te, które budujemy, są coraz bardziej chaotyczne, a nam, ludziom, trudno jest sobie poradzić z tą myślą, trudno porzucić iluzję kontroli. Staramy się je nadal kontrolować, a to często prowadzi do wypalenia zawodowego. Mówię to z własnego doświadczenia, ja też się poparzyłem, też zostałam unieruchomiona przez nieprzewidziane awarie w produkcji.
Wypalenie zawodowe ma miejsce, gdy próbujemy kontrolować coś, czego z natury nie da się kontrolować. Kiedy się wypalamy, wszystko traci sens, bo tracimy chęć zrobienia czegoś nowego, przyjmujemy defensywę i zaczynamy bronić tego, co mamy.
Zawód inżyniera, jak często lubię sobie przypominać, to przede wszystkim zawód twórczy. Jeśli stracimy chęć tworzenia czegoś, wówczas zamienimy się w popiół, zamienimy się w popiół. Wypalają się ludzie, wypalają się całe organizacje.
Moim zdaniem tylko akceptacja twórczej mocy chaosu, tylko budowanie współpracy według jej zasad pomoże nam nie stracić tego, co dobre w naszym zawodzie.
Tego Wam życzę: kochajcie swoją pracę, kochajcie to, co robimy. Ten świat żywi się informacją, my mamy zaszczyt ją karmić. Badajmy więc chaos, bądźmy chaosologami, wnośmy wartość, twórzmy coś nowego, cóż, problemy, jak już się przekonaliśmy, są nieuniknione, a gdy się pojawią, po prostu powiemy „Ops!” i problem zostanie rozwiązany .
Co innego niż Małpa Chaosu?
Tak naprawdę wszystkie te instrumenty są takie młode. Ten sam Netflix zbudował narzędzia dla siebie. Zbuduj własne narzędzia. Przeczytaj zasady inżynierii chaosu i postępuj zgodnie z nimi, zamiast szukać innych narzędzi, które ktoś już zbudował.
Spróbuj zrozumieć, jak psują się Twoje systemy, zacznij je rozkładać i zobacz, jak się sprawdzają. To jest najważniejsze. I możesz szukać narzędzi. Istnieją wszelkiego rodzaju projekty.
Nie do końca zrozumiałem moment, w którym stwierdziłeś, że systemu nie da się uprościć poprzez uproszczenie jego komponentów i od razu przeszedłem do mikroserwisów, które upraszczają system upraszczając same komponenty i komplikując interakcje. Są to zasadniczo dwie części, które są ze sobą sprzeczne.
Zgadza się, mikroserwisy to ogólnie bardzo kontrowersyjny temat. W rzeczywistości upraszczanie części zwiększa elastyczność. Co zapewniają mikroserwisy? Dają nam elastyczność i szybkość, ale z pewnością nie zapewniają nam prostoty. Zwiększają trudność.
Zatem w filozofii DevOps mikrousługi nie są aż tak dobrą rzeczą?
Każde dobro ma drugą stronę. Zaletą jest to, że zwiększa elastyczność, umożliwiając szybsze wprowadzanie zmian, ale zwiększa złożoność, a tym samym kruchość całego systemu.
Na co jednak kładzie się większy nacisk: na upraszczanie interakcji czy na upraszczanie części?
Nacisk jest oczywiście położony na uproszczenie interakcji, bo jeśli spojrzymy na to z punktu widzenia tego, jak z Państwem współpracujemy, to przede wszystkim musimy zwrócić uwagę na uproszczenie interakcji, a nie na uproszczenie pracy każdego z nas z osobna. Ponieważ uproszczenie pracy oznacza zmianę w roboty. Tutaj w McDonald's działa to normalnie, jeśli masz instrukcję: tutaj kładziesz burgera, tutaj polewasz go sosem. To zupełnie nie sprawdza się w naszej pracy twórczej.
Czy to prawda, że wszystko, co powiedziałeś, żyje w świecie bez konkurencji, a chaos, jaki tam panuje, jest tak miły i nie ma w tym chaosie sprzeczności, nikt nie chce nikogo zjeść ani zabić? Jak powinna sobie radzić konkurencja i DevOps?
No cóż, zależy o jakiej konkurencji mówimy. Czy chodzi o konkurencję w miejscu pracy, czy o konkurencję pomiędzy firmami?
O konkurencji usług, które istnieją, ponieważ usługi nie są kilkoma firmami. Tworzymy nowy typ środowiska informacyjnego, a żadne środowisko nie może istnieć bez konkurencji. Wszędzie panuje konkurencja.
Ten sam Netflix, bierzemy ich za wzór do naśladowania. Dlaczego na to wpadli? Ponieważ musieli być konkurencyjni. Ta elastyczność i szybkość ruchu jest właśnie wymogiem bardzo konkurencyjnym, wprowadza chaos do naszych systemów. Oznacza to, że chaos nie jest czymś, co świadomie robimy, bo tego chcemy, jest to coś, co się dzieje, ponieważ świat tego wymaga. Musimy się po prostu dostosować. A chaos jest właśnie wynikiem konkurencji.
Czy to oznacza, że chaos to jakby brak celów? Albo te gole, których nie chcemy oglądać? Jesteśmy w domu i nie rozumiemy celów innych. Rywalizacja tak naprawdę wynika z tego, że mamy jasne cele i wiemy, dokąd zmierzamy w każdym kolejnym momencie. To z mojego punktu widzenia jest istotą DevOps.
Spójrz także na pytanie. Myślę, że wszyscy mamy ten sam cel: przetrwać i robić to
największą przyjemność. Cel konkurencyjny każdej organizacji jest taki sam. Przetrwanie często następuje poprzez rywalizację i nic nie można na to poradzić.
Tegoroczna konferencja odbędzie się 7 grudnia w Technopolis. Zgłoszenia na raporty przyjmujemy do 11 listopada. z nami, jeśli chcesz porozmawiać.
Rejestracja dla uczestników jest otwarta, bilety kosztują 7000 rubli. Dołącz do nas!
Źródło: www.habr.com