9 października 2017

Fenomen DEVOPS na ratunek dla skostniałych i niezbyt wydajnych zespołów w IT (programista i administrator w jednym)

Widowiskowe prezentacje na konferencjach to nie tylko takie, które powalają technologią i frapują, że tego tricku architektonicznego jeszcze nie mamy w naszym systemie :-) Są to również sprawy "miękkiej natury ludzkiej", które w branży IT stanowią często niezbędny pomost pomiędzy tymi, którzy potrafią ale im się nie chce a tymi, którzy mogliby więcej bo mogą dać z siebie więcej dla wyższych idei :-)

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
  • Reagowanie na zmiany ponad podążanie za planem
Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej (src)

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
  1. Continuous build - czyli zmiana to uruchomienie procesów budowania świata/środowiska od zera w konkretnym scenriuszu
  2. Continuous testing - czyli każda zmiana to uruchomienie testów automatycznych i zbudowanie paczki do wdrożenia lub alert
  3. Continuous inspection - przeglądy kodu (Code Review), audyty, zapis historii zmian, autora zmian
  4. 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
  5. Continuous delivery - małe przyrosty zmian dające minimalną wartość produktu to cenny każdy dzień w pracy
  6. 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ć.
  7. Continuous deployment - najlepiej kiedy każda zmiana w kodzie, na dowolnym branchu uruchamia procedury testów automatycznych / integracyjnych. Lubimy spać spokojnie.
  8. 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.  
  9. Continuous recovery - jeśli nie udało się wdrożenie, rollback to nie problem - wycofujemy i próbujemy dalej
  10. 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.







8 października 2017

[ Naprawianie na Kolanie ] Praktyczne naprawianie elektroniki, robotów, błędów w oprogramowaniu, systemów operacyjnych

Odważyłem się i postanowiłem naprawiać różne praktyczne rzeczy materialne i mniej materialne na oczach telewidzów YOUTUBE

NAPRAWIANIE NA KOLANIE - tak nazwałem serię odcinków typu FIX IT ! w moim wydaniu, gdzie prezentuję jak w warunkach amatorskich (domowych) można naprawić, dokonać przeglądu, zmienić i udoskonalić urządzenia codziennego użytku.

Pierwszy odcinek dedykuję użytkownikom iRobot Roomba 650  a szczególnie mojemy mentorowi w tematyce Agile/SCRUM/Kanban/XP. Pomyślałem, że zawsze kilka stówek w kieszeni :-) to nie problem, więc jak to polak z natury ciekawski naprawiam sobie z wizją i fonią zapisaną na youtube.

Problem jaki poruszam ww pierwszym odcinku to to stukanie podczas pracy i związane z tym zanieczyszczenie części mechanicznej (trybów) głównego modułu czyszczącego w iRobot Roomba.
Wiele osób kojarzy firmę iRobot , która wprowadziła wspaniały wynalazek na rynek jakim jest automatyczny "pseudo odkurzacz". Każdy chciałby go mieć, ale nie wszyscy sobie zdają sprawę, że trzeba go stosownie konserwować. Oczywiście, mam tutaj na myśli regularne czyszczenie, bo jak to w mechatronicznych urządzeniach bywa kurz i brud nie wspomagają automatu.






Miłego oglądania i oczywiście naprawiania robotów :-)