Baczność, spocznij, rekrutuj IT

Zdecydowana większość z nas przechodziła etap bycia rekrutowanym. Robimy to poszukując nowej, lepiej płatnej, ciekawszej lub po prostu jakiejkolwiek pracy. Życie, również to zawodowe potrafi nie rozpieszczać. Czasami korzystamy z okazji rozmowy z potencjalnym pracodawcą w celach „treningowych”. Wykorzystanie takiej sytuacji to dla nas sposób na optymalizowanie rekrutacyjnego spięcia, ale też przygotowanie się na bardziej lub mniej typowe pytania. Tych ostatnich nie brakuje w internecie. Dla wytrawnego poszukiwacza nie stanowią one wyzwania. Może on przygotować dowolną odpowiedź na wcześniej znane pytanie (konfabulacje nie-mile widziane). Na swojej drodze spotkałem się z różnym podejściem do tego tematu. W końcu sam też zdecydowałem się stanąć po drugiej stronie mocy. Na podstawie (niestety) swoich wcześniejszych doświadczeń budowałem podejście do rozmów z kandydatami, zakładając, że tak właśnie musi być. Dość szybko przyszedł czas na refleksję. Na moje szczęście dzięki obserwacjom, nie w wyniku negatywnych skutków ubocznych. Ufff.

Podejrzewam, że dzisiaj nawet najlepsi z najlepszych rekruterów, spece nad specami w tym fachu wiedzą jak ciężko bywa w branży IT. Z jednej strony liczba nowych adeptów już nie tak tajnej sztuki programowania (i im zbliżonych) rośnie z roku na rok, ale z drugiej zapotrzebowanie jest jeszcze większe. Rosną też oczekiwania kandydatów. Jak opowiadała kiedyś moja mentorka Joanna Malinowska-Parzydło, zdarza się, że kandydatowi nie wystarczy już ciekawa, dobrze płatna praca. Ważną może okazać się lokalizacja biura, do którego w lecie będzie mógł przyjechać na rowerze, a w zimie na przykład metrem. Możliwość spełnienia pro-ekologicznych oczekiwań może okazać się decydująca. Właściwy dobór kandydata do firmy i firmy do kandydata przekłada się także na aspekty finansowe. Według ZaneBenefits koszty wynikające z zastąpienia dotychczasowego pracownika mogą wahać się od 16% do ekstremalnie ponad 200% (!!!) jego rocznej pensji, w zależności od stopnia jego zaawansowania zawodowego.

Sztukmistrzowie zarządzania usługami IT od dawna zwracali szczególną uwagę na aspekt ludzki. Kultura DevOps, o której pisałem nie jest już jedynie domeną start-upów. Zdecydowanym krokiem wchodzi do środowisk typu enterprise (jak smerf maruda nie cierpię słowa korporacja, choć to niekoniecznie jednoznaczne). I to właśnie DevOps po raz kolejny podkreśla ogromne znaczenie ludzi, ich wzajemnych relacji, współpracy między zespołami, które są wartością w firmach, a swoją pracą dostarczają wartość w ramach świadczonych usług. Dlatego warto już dzisiaj zrobić mały krok wstecz, żeby móc się rozpędzić i zacząć budowanie relacji z nowym pracownikiem już na etapie rozmowy rekrutacyjnej. „Nowy” człowiek musi wiedzieć, że trafia do miejsca, o którym, no może nie marzył, ale będzie z chęcią wstawał codziennie rano z łóżka, żeby wrócić do środowiska, w którym dobrze się czuje i może swobodnie wykonywać zaplanowane obowiązki. Powinien być to zespół, który może obdarzyć zaufaniem, ale też skłonny do tego, żeby tym zaufaniem być obdarzony. Dla przypomnienia wynik skromnej ankiety, którą przeprowadziłem dotyczącej motywacji pracowników. Na drugim (ex aequo) miejscu wśród wymienianych na pierwszym miejscu „motywatorów” znalazła się dobra atmosfera w zespole. Last but not least, jak powiadają amerykanie, niejednokrotnie z ust osób, które zmieniły pracę słyszałem słowa, że najbardziej będzie brakowało im ludzi, z którymi dotychczas pracowali.

Dlatego niech każdy z nas, rekrutowanych poczuje się na rozmowie kwalifikacyjnej nie jak szeregowy pracownik, ale równie ważny i znaczący dla firmy jak jej CEO. Budowanie zespołów z ludzi, nie (tylko) z kompetencji zaprocentuje i da wysoki zwrot z inwestycji nam wszystkim.

Czytaj więcej

Każdy kij ma dwa końce

(Chyba) każda/każdy z nas korzysta dzisiaj z różnego rodzaju usług. Panie mają swoją ulubioną kosmetyczkę, fryzjera, panowie mechanika, który rozwiązuje zagadki techniczne związane z ich samochodami. Zakładam, że w większości przypadków podstawą tych zależności jest cena i jakość świadczonych usług. Te walory mogą jednak nie być wystarczające do zbudowania dobrej relacji, a w jej wyniku długoterminowej współpracy pomiędzy stronami. Dzisiaj oczekujemy czegoś więcej. Dlatego na rynku możemy znaleźć propozycje kompleksowego podejścia do potrzeb klienta. Bazując na przykładzie branży budowlanej: od zakupu i związanych z tym formalności, przez budowę, do wykończenia domu „pod klucz”. Prawdopodobnie wszyscy wiemy, że wymagający klienci usług IT mają podobne oczekiwania. W dobie przedsiębiorczości, każdy klient chciałby, abyśmy jego serwisem IT zarządzali jak własną firmą, która działa sprawnie, przynosi korzyści. W przypadku kryzysu będziemy w stanie przygotować odpowiedni plan naprawczy, minimalizując negatywny wpływ na usługę IT. Na tej podstawie to właśnie korporacyjny „ownership” często króluje na liście życzeń naszych partnerów w biznesie. Proaktywność, choć to zwrot brzmiący mało patriotycznie, doskonale wpisuje się w ramy podejścia do klienta, zapewne nie tylko w obszarze usług IT. Czasami taką postawę nazywam czytaniem klientom w myślach, ale faktycznie raczej należałoby to zdefiniować jako wręcz wyprzedzanie ich myśli. Rosnące oczekiwania, którym niejednokrotnie trudno sprostać powodują, że wytrwali dostawcy usług IT budują swoją markę w oparciu o dojrzałość wykonywanych procesów. Zapewnienie ich powtarzalności oraz właściwe radzenie sobie z pojawiającymi się problemami powinno prowadzić do uzyskania stabilności. Dzięki temu buduje się zaufanie oraz prawdziwe partnerstwo. Przykładowo – dobrej jakości dokumentacja i dostęp do przejrzystych informacji o aktualnych pracach, pozwalają zachować biznesowi kontrolę, mimo ogromnego obciążenia innymi obowiązkami. Umożliwia także oddanie jeszcze większej swobody działania partnerowi. Ostrożnie – ten kij może mieć dwa końce. W przypadku poszukiwania zmian, osiągnięta dojrzałość pozwala decydentom na sprawną zmianę dostawcy serwisu IT. Daje zabezpieczenie przed potencjalnym monopolem. Dochodzimy tutaj do modnego ostatnio w środowisku ITSM tematu związanego z zarządzaniem dostawcami w ramach organizacji – SIAM, o którym wspominałem już jakiś czas temu. Wszystko wskazuje jednak na to, że potrzeby naszych klientów w obszarze IT nieustannie rosną. Zamiast więc boczyć się na swoją konkurencję, bądźmy wyjątkowi. Pokażmy, że umiemy współpracować ze wszystkimi na równym poziomie, nie tylko ze swoimi usługodawcami. Pracy powinno starczyć dla wszystkich. Przynajmniej na razie.

Czytaj więcej

Bitwa o usługi IT

W początkach rozwoju ruchu DevOps jego filozofia wprowadzała wiele nowych pomysłów, szczególnie w kwestii współpracy i przejrzystości w ramach dostarczanych usług. Chociaż na pierwszy rzut oka wydawało się to innowacyjnym podejściem, faktycznie ITIL już od dłuższego czasu proponował podobne praktyki. W czasach kiedy powstawały podwaliny ITIL’a nie mieliśmy dostępu do nowoczesnych mediów społecznościowych, a używane na co dzień aplikacje wymagały pomocy drugiego człowieka znającego się na technologii IT. Rozwój techniki i mnogości zadań towarzyszących codziennej pracy doprowadził do wytworzenia się procesów.

PPT
Podejście do zarządzania usługami w oparciu o DevOps, źródło: http://www8.hp.com/h20195/V2/GetPDF.aspx/4AA5-5748ENW.pdf, 25.01.2016

Wymienione trzy filary usług świadczonych w oparciu o metodykę DevOps według Hewlett-Packard Enterprise (patrz Rysunek powyżej), czyli People – Ludzie, Process – Procesy, Technology – Technologia, to przecież nic więcej jak modyfikacja dotychczas przedstawianego przez ITIL modelu 4P (People, Processes, Products, Partners), opisanego w ramach cyklu życia Service Delivery. Mimo tego DevOps zyskuje co raz więcej sprzymierzeńców. W porównaniu do ITSM, w ramach którego aby dokonać dowolnej zmiany, należy spełnić masę formalności, zapewnia szybkość i elastyczność. Jednak zanim dojdziemy do pochopnych wniosków, że podejście DevOps jest zawsze tanie i proste warto dokonać porównania obu propozycji w Tabeli poniżej.

Tabela. Porównanie zakresów wybranych procesów ITSM i DevOps

Zakres ITSM/ITIL Zakres DevOps
Zarządzanie incydentami Optymalizacja zaangażowania człowieka w interakcje i eskalacje incydentów. Świadomość kodu i infrastruktury, które same, automatycznie mogą przywracać poprawność swojego działania.
Zarządzanie problemami Analizowanie trendów pomiędzy systemami i systemowe eliminowanie problemów. Korelacja zewnętrznych czynników, które mogą wpływać negatywnie na działanie usługi i wykrywanie potencjalnych źródeł awarii.
Zarządzanie konfiguracją Budowanie powiązań i mapowanie zależności pomiędzy komponentami usługi. Wykorzystanie wspólnych definicji w celu automatycznego mapowania komponentów usługi.
Zarządzanie zmianą Przygotowanie operacyjne zmian w celu minimalizacji ryzyka. Wykorzystanie zaufanych modeli konfiguracji w celu wykrywania ryzyka i automatyzacji zmian z wbudowaną opcją automatycznego przywracania usługi.
Zarządzanie wiedzą Zbieranie informacji i udostępnianie jej w ramach zarządzanych systemów i procesów. Dzielenie się informacją w ramach bieżącej współpracy pomiędzy dev i ops.

źródło: M. Hooper, ITSM vs. DevOps – Agility vs. Control – is this really battle royale http://itstrategizer.com/2016/01/20/itsm-vs-devops-agility-vs-control-is-this-really-battle-royale , 28.01.2016

Szczególnie w przypadku starszych technologicznie rozwiązań IT (ang. legacy) zastosowanie podejścia opartego o ITIL może zapewnić większą kontrolę nad dostarczanymi usługami. Pozwala na zwiększenie przewidywalności, budowania odpowiedzialności i efektywności, ale nie wspomaga zwinności. Mimo wszystko wsparcie ITSM prowadzi do budowania podwalin usługi, umożliwiających zwiększenie szybkości zmian poprzez automatyzację. Płynne przejście organizacji na bazie ustrukturyzowanego ITSM do elastycznego i podatnego na zmiany DevOps to zapewnienie świadczenia usług pozwalających reagować na zapotrzebowania dzisiejszego biznesu, którego charakteryzuje szybka zmienność.

Czytaj więcej

Ops w Dev i vice versa

W trakcie awarii usług świadczonych przez firmę Amazon w 2012 roku[1], która wpłynęła na działanie takich serwisów internetowych jak Redit, czy Imgur nikt z pracowników nie musiał dotykać firmowych urządzeń. Nikt nie biegał od serwera do serwera, aby sprawdzać jego działanie, co też z racji rozproszonych lokalizacji byłoby praktycznie niemożliwe. Ta sytuacja pokazuje jak dzisiejsze operations różni się od tego sprzed dwudziestu, trzydziestu lat. Mamy zdecydowanie mniej pracowników w roli utrzymaniowej, a liczba serwerów przypadających na jedną osobę jest zdecydowanie większa. W związku z tym nastąpiło również przesunięcie części kosztów z działów operacyjnych do działów rozwoju. Mimo tego główny cel pozostał nie zmieniony. Usługi świadczone klientom muszą pozostać na oczekiwanym poziomie. Nie jest jednak kluczem do sukcesu całkowite przeniesienie specjalistów utrzymania do działów rozwoju. Nawet najlepszy programista nie jest w stanie zagwarantować, że jego oprogramowanie będzie odporne na wszystkie możliwe zakłócenia w działaniu. Najważniejszym aspektem jest to, aby nie pozwalać developerom odciąć się od konsekwencji ich pracy i potencjalnych błędów, które popełnili w trakcie pisania kodu. Prowadzi to do budowania i poszerzania odpowiedzialności w firmie świadczącej usługi IT już nie tylko w ramach ich eksploatacji, ale również rozwoju.

źródło: http://devopscube.com
źródło: http://devopscube.com

Dzielenie się odpowiedzialnością ma także inne zalety. Dotychczasowo developerzy odpowiedzialni byli za swoją pracę tylko do momentu wdrożenia zmiany. Od momentu pojawienia się aplikacji na środowisku produkcyjnym za wszystkie błędy odpowiadali operatorzy. W przypadku pojawienia się incydentu często dochodziło do sytuacji wzajemnego obarczania się stron, czy wytykania palcem popełnionych błędów. Jedni mówili o złym kodzie, który zawiera dziury, drudzy o nieprawidłowym wdrożeniu, czy nieodpowiednim przygotowaniu do implementacji zmiany. W efekcie pracy w oparciu o DevOps zespoły przy wykorzystaniu dostępnych procesów i narzędzi mogą współpracować przy rozwiązywaniu incydentów i problemów. W wyniku tej pracy i zebranych doświadczeń powstają jeszcze lepsze aplikacje, jeszcze bardziej odporne na zakłócanie ich pracy. Zatem zamiast budować kolejne procedury, które jako podstawę swojego działania zakładają udział ludzi, buduje się takie rozwiązania, które systemowo pozwalają się zabezpieczyć przed codziennymi przerwami w działaniu.

[1] Por. B. Butler, Amazon EBS failure brings down Redit, Imgur, others, Network World, 2012

Czytaj więcej

Za kulisami organizacji, czyli wprowadzenie do DevOps

W znaczącej ilości przedsiębiorstw dotychczasowy model świadczenia usług IT oparty był na klasycznym podejściu. Jako bazę przyjmowało się założenia wynikające z metodologii Information Technology Infrastructure Library (ITIL). W wyniku stosowania takiego podejścia struktury organizacyjne departamentów, czy działów IT dzielone były na pierwsze, zajmujące się tworzeniem nowych lub rozwojem dotychczasowych usług IT – Development (ang. rozwój), w skrócie Dev. Drugą grupa były jednostki Operations (ang. operacje), w skrócie Ops, które odpowiedzialne są za wsparcie operacyjne, nazywane często utrzymaniem produkcyjnych usług, czyli tych, z których codziennie korzystają docelowi użytkownicy końcowi. Za podziałem organizacyjnym przedsiębiorstwa idą odpowiadające im procesy i procedury związane ze świadczeniem wspomnianych usług IT.
Za początek historii DevOps przyjmuje się rok 2008. DevOps zrodziło się z potrzeby biznesowej, której oczekiwaniem było zapewnienie szybszej odpowiedzi IT na zmiany rynkowe. Nowe podejście zostało zaprojektowane w taki sposób, aby zapewnić dostarczanie oprogramowania wysokiej jakości do rąk użytkowników końcowych w krótszym czasie. Ustawiczne dostarczanie takich rozwiązań wymagało, aby ich programiści, testerzy, projektanci wyglądu i jednostki operacyjne współpracowały efektywnie przy wykorzystaniu istniejących procesów oraz wzajemnych informacji zwrotnych.

devops
Graficzna reprezentacja biznesowej potrzeby wdrożenia modelu DevOps

To właśnie w roku 2008 Patrick Debois, który podejmował się różnych ról z obszaru IT pracując jako programista, administrator systemów, tester, czy kierownik projektów przedstawił na konferencji „Agile conference” w Toronto propozycję nowego podejścia. Dążył do rozwiązania istniejących konfliktów pomiędzy światami inżynierów rozwoju i wsparcia oprogramowania, które uniemożliwiały szybkie wdrażanie zmian dobrej jakości. W naturalny sposób Debois stał się liderem zagadnienia, inspirując inne osoby działające w obszarze IT, aby podjąć się tego wyzwania. W roku 2009 w Belgii, na konferencji O’Reilly “Velocity Conference” dwóch pracowników Flickr’a (internetowego serwisu służącego do przechowywania, udostępniania i zarządzania zdjęciami) John Allspaw oraz Paul Hammond zaprezentowali wykład zatytułowany „Dziesięć plus zastosowań na dzień: współpraca Dev i Ops w firmie Flickr” (org. “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.”). Przemówienie skierowane do sali pełnej programistów odtworzyło codzienną sytuacje, kiedy obie strony Dev i Ops, wzajemnie zrzucają na siebie winę za niepowodzenia nowych wdrożeń. W środowisku IT taka sytuacja określana była często mianem: „to nie mój kod, to twoje maszyny [zawiodły]”. Na bazie studium przypadku Allspaw i Hammond pokazali, że jedynym sposobem na odniesienie sukcesu w tworzeniu, testowaniu i wdrażaniu nowego oprogramowania jest integracja działów rozwoju i utrzymania tak, aby granica pomiędzy nimi była niewidoczna. Wystąpienie uzyskało duże uznanie, dowodząc, że efektywna współpraca pomiędzy światami Developmentu i Operations jest możliwa. W tym czasie Debois zainspirowany obejrzaną prezentacją pracowników Flickr’a za pośrednictwem relacji internetowej, postanowił zorganizować własną konferencję. Nazwał ją „Devopsdays”. Wkrótce po tych wydarzeniach przyjęła się przyjazna nazwa koncepcji, skrócona do jednego terminu DevOps. Dzisiaj nieco lepiej rozumiejąc naturę istniejących wyzwań, DevOps definiuje się jako wspólną pracę inżynierów wsparcia i rozwoju usług IT, którzy biorą udział w całym cyklu życia usługi zaczynając od jej projektowania, przez implementację, na utrzymaniu produkcyjnym kończąc.

Artykuł jest fragmentem pracy dyplomowej „Wdrożenie i zarządzanie usłgą IT w oparciu o model DevOps” autorstwa własnego. Przy jego powstawaniu korzystano z materiałów: Richard Rapaport, A short history of DevOps, http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html, Marketing Department of WIRED and Ars, 2014

Czytaj więcej