Jak wiadomo z ciekawej sztuki V jak Vendetta "idea jest niezniszczalna" i w tym wpisie chętnie poruszę temat spraw nie technicznych, które wspierają ludzi technicznych. Idei, które trwają w świecie DevOps :-)
Jak się zaczęło to całe DevOps i gdzie po drodze spotkali się ludzie z IT?
Na początku był Dev a potem pojawił się Ops albo odwrotnie, zależnie od źródeł ... ;-)Zmierzam do tego, że na początku ery komputerów i informatyki istnieli deweloperzy, którzy stworzyli maszyny, po czym dalej byli zajęci kodowaniem i mieli misje rozwoju oprogramowania. Zabrakło im czasu na utrzymywanie i zarządzanie technicznymi aspektami ich dzieła i pojawił się zawód administratora w informatyce.
Celowo bardzo ten wstęp uprościłem, gdyż te dwie role i do tej pory rozdzielne zawody: programista / developer oraz sysops / ops / administrator za sprawą tzw. chęci stały się jednością:)
"Banalne" założenie – łączymy wysiłki zespołów rozwoju i utrzymania (Development i Operations).
Tak na serio poruszam temat dość niesamowity w branży IT, kiedy dwie popadające w skrajności - tak, nie przesadzam - grupy informatyków o podobnych zainteresowaniach zawodowych ścierały się ze sobą i utrudniały sobie prace a tu nagle ....
Z pomocą przyszedł tzw. Agile wraz z manifestami zwinności w codziennym postępowaniu. Niczym kodeks, który stanowi bazę dla wszelkich czynności zawodowych zjawia się: Agile Manifesto , który wspomógł ideologicznie cały świat IT.
Istotnie są tacy, którzy się temu nie poddali - jak zwykle "mądrzejsi" - ale nie o nich jest ten wpis. Skupiam się na ludziach, którzy lubią na co dzień ryzykować i eksperymentować, którzy porzucili wygodną strefę komfortu na rzecz zwinności w pracy.
Oto zasady, którymi posługuje się na stale od wielu lat:
Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:
- Ludzie i interakcje ponad procesy i narzędzia
- Działające oprogramowanie ponad obszerną dokumentację
- Współpracę z klientem ponad formalne ustalenia
Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej (src)
- Reagowanie na zmiany ponad podążanie za planem
Otóż, naturalnie zainteresowanie programowaniem ze strony administratorów systemów operacyjnych oraz zainteresowanie budową systemu Linux ze strony programistów, czy inżynierów oprogramowania spowodowało falę pozytywnych kreacji. Nie teoretyzuję tutaj, bo widzę na co dzień zadowolonych adminów, software developerów, którzy nazywają siebie DevOpsami.
Nazwałem zjawisko w tytule jako Fenomen DevOps dlatego, że nie znam branży, w której dwa kierunki rozwoju zawodowego spotykają się tak ochoczo i brną we współpracę.
Są widoczne naturalnie pozytywne skutki tego połączenia w wielu organizacjach. Wiele firm z TOP 500 już wdrożyła Agile, SCRUM, czy Lean ew. Kanban i po latach nauki mogą cieszyć się zwinnością w produkcji zmian w swoich produktach.
Co zyskujemy wdrażając w organizacji kulturę DevOps ?
Argumenty poniższe są zapożyczone z praktyki:
- zadowolenie wśród pracowników i brak barier branżowych (dyskusje na różne tematy)
- otwartość i transparentność w działaniach (każdy z każdym współpracuje jak najlepiej potrafi)
- utrzymanie i rozwój produktów przez wiele zwinnych osób (bo im się chce, a nie muszą)
- zespoły produkujące są też utrzymującymi swoje produkty (bo wiedzą o nich wszystko)
- zespoły monitorują swoje wdrożenia i produkty metrykami biznesowymi i technicznymi (wiedzą przed awarią, że zasoby niebawem się skończą i zareagują na automatyczny alarm)
- automatyzują pracę, która jest powtarzalna i monotonna (bo są wygodni i maszyna zrobi to zawsze tak samo, w tym czasie mogą pójść na herbatkę)
- dzielą się ze światem Open Source, bo biorą z niego też niektóre składowe swoich produktów
- pozwalają na krytykę innym ze swojej pracy i dyskutują o tym, wyciągają wnioski (wartościowa cecha ludzka)
- panują nad kodem i wiedzą co zrobić, aby koszt utrzymania nie rósł stale (bo są inżynierami)
- motywują się wzajemnie przez dzielenie pasjami zawodowymi (taki to wesoły świat IT)
- razem z biznesem patrzą sobie na ręce, bo mają metryki i mogą (biznes też się uczy wiele z właściwych metryk n.t. zdarzeń w produkcie)
- robią Hackatony, aby udowodnić sobie i innym, że zabawki zrobione w 24h potrafią zaskakiwać oraz poznają kolegów z innych odległych oddziałów (same atuty)
- drobne zmiany, które można szybko zobaczyć na produkcji są cenniejsze niż 5 m-cy straty
- eksperymentowanie to domena ludzi odważnych (czyli DevOpsów)
Liczby w różnych źródłach mówią o tym fenomenie dość konkretnie.
Z jakimi rozwiązaniami wiąże się DevOps ?
Celowo pozostawiłem nazwy w języku angielskich, bo ozn. bardzo konkretne działania
- Continuous build - czyli zmiana to uruchomienie procesów budowania świata/środowiska od zera w konkretnym scenriuszu
- Continuous testing - czyli każda zmiana to uruchomienie testów automatycznych i zbudowanie paczki do wdrożenia lub alert
- Continuous inspection - przeglądy kodu (Code Review), audyty, zapis historii zmian, autora zmian
- Continuous integration - jeśli zbudujemy swój projekt, to jeszcze zintegrujmy go z resztą usług - jak zadziałają nie tylko nasze testy ale też innych, to jest bardzo dobrze
- Continuous delivery - małe przyrosty zmian dające minimalną wartość produktu to cenny każdy dzień w pracy
- Continuous configuration enforcement - wiem, gdzie przestawić przełączniki mojej aplikacji i wszelkie paramerty. Nie potrzebuję wdrożenia, aby zmienić właściwości i warunki pracy usług. Zawsze inni widzą, co zmieniałem ostatnio i mogą w trakcie awarii odpowiedni szybko zareagować.
- Continuous deployment - najlepiej kiedy każda zmiana w kodzie, na dowolnym branchu uruchamia procedury testów automatycznych / integracyjnych. Lubimy spać spokojnie.
- Continuous monitoring - na każdym etapie wytwarzania, testowania, wdrożenia, działania staraj się widzieć metryki a najlepiej podepnij do nich automatyczny system alarmujący w SMS lub dzwoniący. Tak przy każdej zmianie testuj też system alertujący, uratuje to Twój swiat.
- Continuous recovery - jeśli nie udało się wdrożenie, rollback to nie problem - wycofujemy i próbujemy dalej
- Continuous scaling - cóż, w święta większy ruch, to nie problem jeden parametr lub automatyczne skalowanie instancji lub maszyn spowoduje, że wydajność usług nie spadnie
Antywzorzec jaki zauważyłem w rozumieniu DevOps to jest robienie oddzielnych integracji zespołów DEV i odzielne OPS, to czyni świat IT gorszym a ludzi klasyfikuje niepotrzebnie na dewów i adminów. Ludzie nie lubią być sortowani, ale bardzo cenią sobie możliwość poznania zdania innych stron.
Inny problem to zamknięte w sobie i niewspółpracujące typki o dziwnych charakterach - cóż, warto być wyrozumiałym i dać im czas oraz szansę rozwoju. Po jakimś czasie będą bardzo wdzięczni za otworzenie oczu i wytarcie mgły sprzed ich oczu ;-) kiedy zobaczą swój kod na produkcji pod wysokim obciążeniem i kiedy miliony polaków przed swoimi monitorami klika ten "mój guzik" :-)
Jeśli nadal zastanawiasz się, czym jest DevOps i nie wiesz, jak wdrożyć u siebie zapraszam do dyskusji. Chętnie odpowiem o tym, jak ja to rozumiem i poznam też inne punkty widzenia.
Posty
Brak komentarzy:
Prześlij komentarz