Czas na postanowienia noworoczne?

On 8 stycznia 2016 by puppetmaster

Świetnie się składa, bo PuppetLabs opublikował właśnie zawierającego 5 rozdziałów mini-ebooka (20 stron), Sprawdzona droga do wydajnego zespołu IT. Można go ściągnąć za darmo jako PDF. Wydanie opisuje:

  1. Korzyści i koszty budowy zespołu – złożoność projektów i rozwiązań wymusza zmiany stylu pracy i DevOps wydaje się być tu pomocny, ale jak przekonać swój zespół do tej koncepcji i nie wywołać u nich paniki związanej ze zmianą modelu pracy, przejmowaniem części kompetencji innych zespołów (programiści⇄administratorzy), wdrażaniem procedur dotykających błędów, których konfrontacji dotąd wszyscy unikali („to nigdy nie działało”, „tego się nie da naprawić”) i ogromem nowych narzędzi do nauczenia? Nie da się uniknąć nakładu pracy wymaganej do tej przemiany, ale pomóc może czytelne określenie korzyści, jakie cała organizacja może dzięki nim ponieść w stosunkowo krótkim czasie. Pewnych kosztów nie da się uniknąć, bo wydajniej pracujący zespół to także ryzyko wypalenia i nowe zadania do wykonania (miejsce na nowe wakaty). Warto też być może zaangażować doświadczonego specjalistę, który będzie w stanie pokazać w jaki sposób zapoczątkować zmiany;
  2. Stawianie czoła największym problemom budowy zespołu – jak radzić sobie z różnymi celami (operatorzy⇝stabilność; deweloperzy⇝szybkość wdrożeń; bezpieczeństwo⇝stabilność produktu i procesu) i jak stworzyć wspólny cel; jak nie zniechęcać się, kiedy występują początkowe problemy; jak stawiać czoła zmianom kulturalnym (przekuć strach i ryzyka w zespole w atrakcyjne nowe umiejętności i bardziej różnorodną pracę); jak identyfikować i radzić sobie z zakorzenionymi mitami (jak np. „większa szybkość wdrożeń to mniejsza stabilność”); wreszcie co ze starymi (legacy) systemami, które za nic nie chcą się wpasować w nowy model?
  3. Opracowanie struktury zespołu wspierającej wysoką wydajność – kluczem do zrozumienia potrzeb poszczególnych antagonizujących zespołów jest „poczucie ich bólu” (np. dla dewelopera będzie to udział w cotygodniowej rotacji, czyli wsparcia systemu poza godzinami pracy; dla operatorów udział w systemie CI i akceptowaniu zmian – code review); warto również doceniać umiejętności poszczególnych pracowników i zachęcać ich aby dzielili się wiedzą (np. organizując atrakcyjne w udziale wewnętrzne szkolenia); dobrą strategią jest również początkowy udział w transformacji jedynie przez najbardziej doświadczonych, kiedy wszyscy inni pracują „po staremu” (pozwoli to opracować narzędzia i workflow, który potem może być powielany i wykonywany przez większą liczbę osób, aż do pełnej adopcji); nie warto też poprzestawać na deweloperach i operatorach (dobre skutki transferu wiedzy można zyskać włączając osoby odpowiedzialne np. za projektowanie i bezpieczeństwo); przy łączeniu kompetencji nie wolno też zapominać o tradycyjnych zadaniach, jakie muszą być wykonywane (typowo przypadające osobie określanej jako „Manager IT”);
  4. Wybór odpowiednich narzędzi i procesów – należy sobie zdawać sprawę, że DevOps wykształcił cały ekosystem narzędzi i wybór pośród nich może być trudny (a, co za tym idzie, bazować na odpowiedziach na konkretne potrzeby zespołu, nie samej chęci wdrażania nowych, fajnych, narzędzi); należy pamiętać, że kluczem do automatyzacji jest postrzeganie infrastruktury jako kod (IaC); dobrą wskazówką do automatyzacji jest zawsze wytypowanie najbardziej czasochłonnych (w ujęciu miesięcznym, a więc powtarzających się – często też powodujących problemy i niespójności) manualnych czynności; warto postawić na narzędzia, które mogą rozwiązywać więcej niż jeden problem; podstawowe obszary narzędzi DevOps (największe początkowe zyski niesie wdrożenie pierwszych dwóch, ale ich wzajemna integracja wielokrotnie będzie wzmaciać siłę ich działania):
    • Kontrola wersji (np. GitHub, Mercurial, Perforce, Subversion, Team Foundation Server)
    • Zarządzanie konfiguracją (np. Puppet i spółka)
    • Ciągła integracja (np. Atlassian Bamboo, Go, Jenkins, TeamCity, Travis CI)
    • Wdrażanie (np. Capistrano, Ansible)
    • Monitoring (np. New Relic, Nagios, Splunk, AppDynamics, Loggly, Elasticsearch)
  5. Kluczowe etapy wdrożenia – czyli skrócona „mapa drogowa” dla początków transformacji:
    1. Zautomatyzuj wszystkie „bolesne” procesy – „bolesne”, czyli takie, które (1) wykonywane są często i zajmują sumarycznie dużo czasu (zmień rzemiosło w fabrykę) i (2) takie, które wykonywane są rzadko i są złożone, a zatem zajmują dużo czasu (nie wymyślaj koła na nowo, otwórz „biuro patentów” i używaj ponownie jak najwięcej zgromadzonego tam know-how);
    2. Ustandardyzuj procesy i narzędzia – musisz zacząć myśleć o swojej infrastrukturze w ujęciu kodu i musisz ten kod przechowywać w systemie kontroli wersji – to największa rewolucja, ale na niej opierają się wszystkie późniejsze procesy i narzędzia; używaj wspólnych i wspieranych rozwiązań, nie pozwól na to, żeby każdy nowy projekt korzystał z kolejnego, „lepszego” workflowu, którego potem nikt nie będzie w stanie utrzymywać;
    3. Projektuj ulepszenia z uwzględnieniem wewnętrznych klientów – wreszcie po podstawach czas na zautomatyzowanie procesów wdrażania aplikacji oraz monitoring; tutaj odpowiedź jest prosta: te procesy powinny być w pełni automatyczne (a więc zawarte w cyklu ciągłej integracji); jest też prosta odpowiedź na pytanie „czy nie monitorujemy zbyt dużo?” i brzmi ona „nie” – każde statystyki można sensownie agregować i wykorzystywać (oprócz tych, których nie zbieraliśmy, a więc nie dysponujemy historycznymi danymi)
    4. Nie bój się zmian mających na celu ciągłe budowanie wiedzy i samodoskonalenie – kluczem do sukcesu w świecie, gdzie wciąż pojawiają się nowe technologie i rozwiązania jest zostanie organizacją edukacyjną; wspieraj dążenie do doskonalenia wiedzy, nie tylko kupując książki  i wysyłając ludzi na szkolenia, ale pozwól im na wymianę wiedzy między sobą (bez siedzenia po godzinach) i daj możliwość, aby stali się ekspertami w swoim środowisku (np. przez udział w roli prelegentów na branżowy konferencjach).

Wśród cytowanych przedsiębiorców, którzy brali udział w podobnej transformacji są: Disney czy Salesforce.

Kadr z prezentacji "How Spotify Helps Their Engineers Grow" Chris Angove

Kadr z prezentacji „How Spotify Helps Their Engineers Grow” Chris Angove

Zachęcam też do lektury tłumaczenia Karty operacyjnej dla administratorów (T.Limoncelli, P.Grace). Jest to ankieta zawierająca proste pytania tak/nie, która pozwoli ci oszacować, jakie z podstawowych technik operacyjnych są stosowane, a jakie jeszcze nie, a ze względu na opisane korzyści, warto byłoby rozważyć ich wdrożenie. Pytania zawierają się w kilku kategoriach:

  1. Działania reprezentacyjne – polityki i metody komunikacji (m.in. systemy ticketowe, zdefiniowanie zakresu wsparcia, śledzenie wydajności i raportowanie);
  2. Progresywna praca zespołowa – nowoczesne narzędzia pracy grupowej (git, wiki, bugtrackery, post mortem);
  3. Praktyki operacyjne – czyli co zrobić, aby nie powtarzać własnych błędów (OpsDoc, monitoring, rotacja, SDLC);
  4. Praktyki automatyzujące -nasza ulubiona automatyzacja, i nie tylko (OpsDoc, monitoring, rotacja, SDLC);
  5. Zarządzanie flotą – inwentaryzacja i provisioning (automatyczna instalacja systemów, obsługa kontraktów wsparcia, obsługa amortyzacji starzejących się komponentów);
  6. Wprawa przed katastrofą – minimum „Disaster recovery”, na który powinno być stać każdy zespół (redundancja systemów i sieci, testowanie odtwarzania backupów, dostęp zdalny);
  7. Bezpieczeństwo – bo nie warto oddzielać tematów bezpieczeństwa od codziennej operacyjnej praktyki, zdecydowanie lepiej (taniej i bezpieczniej), aby te tematy były ze sobą połączone.

Zapraszam do lektury! I działania!

…a rezultaty, jak zauważa Jez z Heartland Payment Systems, mogą być wspaniałe: „Skończ z gaszeniem pożarów, ujednolicaj platformy, daj ludziom spać po nocach, pozwól im odzyskać swoje życie prywatne i zamiast utrudniać, ułatwiaj ich pracę przy dewelopowaniu oraz utrzymaniu, a staną się odnoszącymi sukcesy biznesmenami”.

 

Comments are closed.