Wiadomo, że kompetencje CTO są weryfikowane dopiero po drugim podejściu do pełnienia tej roli. Bo jedno to kilka lat pracy w firmie, stopniowe zyskiwanie większej odpowiedzialności w tym samym kontekście kulturowym, a zupełnie inna sprawa to objąć stanowisko dyrektora technicznego w firmie z plecakiem spadku i całą masą problemów sprytnie zamiecionych pod dywan.

W tym sensie doświadczenie Leona Flejera, które dzielił na DevOpsConf, nie jest może wyjątkowe, ale pomnożone przez staż i liczbę różnych ról, które przez 20 lat zdążył na siebie przyjąć, jest bardzo pomocne. Poniżej chronologia wydarzeń z 90 dni oraz wiele anegdot, z których miło się śmieje, gdy zdarzają się komuś innemu, ale nie jest już tak zabawnie, gdy spotykają nas osobiście.

Leon opowiada w kolorowy sposób po rosyjsku, więc jeśli masz 35-40 minut, polecam obejrzeć wideo. Poniżej znajduje się wersja tekstowa dla zaoszczędzenia czasu.

Pierwsza wersja raportu była dobrze zorganizowanym opisem pracy z ludźmi i procesami, zawierającym przydatne rekomendacje. Jednak nie oddawała wszystkich niespodzianek, które napotkałem po drodze. Dlatego zmieniłem format i przedstawiłem problemy, które w nowej firmie wyskakiwały przed mną, jak diabeł z pudełka, oraz metody ich rozwiązania w chronologicznym porządku.

Miesiąc przed

Jak to bywa w wielu dobrych historiach, ta zaczęła się od alkoholu. Siedzieliśmy z znajomymi w barze, a jak to bywa wśród informatyków, każdy opowiadał o swoich problemach. Jeden z nich właśnie zmienił pracę i opowiadał o swoich kłopotach zarówno z technologią, jak i z ludźmi oraz zespołem. Im dłużej słuchałem, tym bardziej rozumiałem, że powinien po prostu mnie zatrudnić, bo to właśnie takie problemy rozwiązywałem przez ostatnie 15 lat. Powiedziałem mu to, a następnego dnia spotkaliśmy się już w zawodowej atmosferze. Firma nazywała się Teaching Strategies.

Teaching Strategies jest liderem na rynku programów edukacyjnych dla dzieci w bardzo wczesnym wieku – od narodzin do trzech lat. Tradycyjna firma „papierowa” istnieje już od 40 lat, a cyfrowa wersja SaaS platformy od 10. Stosunkowo niedawno rozpoczął się proces dostosowywania cyfrowych technologii do standardów firmy. 'Nowa' wersja została uruchomiona w 2017 roku i była prawie jak stara, tylko działała gorzej.

Najciekawsze jest to, że ruch w tej firmie jest bardzo przewidywalny – z dnia na dzień, z roku na rok można bardzo dokładnie przewidzieć, ilu ludzi przyjdzie i kiedy. Na przykład między 13 a 15 godziną wszystkie dzieci w przedszkolach idą spać, a nauczyciele zaczynają wprowadzać informacje. I tak dzieje się każdego dnia z wyjątkiem weekendów, ponieważ w weekendy prawie nikt nie pracuje.

Zanim przejdę do sedna, zauważę, że rozpocząłem swoją pracę w okresie największego rocznego ruchu, co jest interesujące z różnych powodów.

Platforma, która miała zaledwie 2 lata, miała specyficzny stos technologiczny: ColdFusion i SQL Server z 2008 roku. ColdFusion, jeśli nie wiesz, a prawdopodobnie nie wiesz, to taka wersja PHP dla firm, która pojawiła się w połowie lat 90-tych, i od tego czasu nawet o nim nie słyszałem. Były tam także: Ruby, MySQL, PostgreSQL, Java, Go, Python. Ale główny monolit działał na ColdFusion i SQL Server.

Problemy

Im więcej rozmawiałem z pracownikami firmy o pracy i problemach, z jakimi się borykają, tym bardziej zdawałem sobie sprawę, że problemy mają nie tylko charakter techniczny. Dobra, technologia jest stara – nie pracowaliśmy na takiej, ale były problemy z zespołem i procesami, a firma zaczęła to rozumieć.

Tradycyjnie specjaliści techniczni siedzieli w kącie i zajmowali się swoją pracą. Ale coraz więcej biznesu zaczęło przechodzić właśnie przez wersję cyfrową. Dlatego w firmie, w ostatnim roku przed rozpoczęciem mojej pracy, pojawiły się nowe stanowiska: rada dyrektorów, CTO, CPO oraz dyrektor QA. Innymi słowy, firma zaczęła inwestować w sferę technologiczną.

Ślady ciężkiego dziedzictwa były nie tylko w systemach. W firmie były procesy legacy, ludzie legacy, kultura legacy. Wszystko to trzeba było zmienić. Pomyślałem, że na pewno nie będzie nudno i postanowiłem spróbować.

Dwa dni przed

Dwa dni przed rozpoczęciem nowej pracy przyjechałem do biura, wypełniłem ostatnie dokumenty, poznałem zespół i odkryłem, że w tym czasie zespół boryka się z problemem. Polegał on na tym, że średni czas ładowania stron wzrósł do 4 s, czyli dwa razy więcej.

Sądząc po wykresie, ewidentnie coś się stało, chociaż nie wiadomo co. Okazało się, że problem tkwił w opóźnieniu sieci w centrum danych: 5 ms opóźnienia w centrum danych przekładało się na 2 s dla użytkowników. Dlaczego tak się stało, nie wiedziałem, ale w każdym razie okazało się, że problem leży w centrum danych.

Dzień pierwszy

Minęły dwa dni, a w mój pierwszy dzień pracy odkryłem, że problem nadal istnieje.

Przez dwa dni strona ładowała się średnio przez 4 sekundy. Zapytałem, czy odkryto, w czym leży problem.

— Tak, otworzyliśmy zgłoszenie.
— I co?
— Cóż, jeszcze nie otrzymaliśmy odpowiedzi.

Wtedy zrozumiałem, że wszystko, o czym wcześniej mi mówiono, to tylko mały wierzchołek góry lodowej, z którym trzeba walczyć.

Jest dobre powiedzenie, które bardzo pasuje do tej sytuacji:

„Czasami, aby zmienić technologię, trzeba zmienić organizację.”

Ponieważ rozpocząłem pracę w najbardziej obciążonym okresie roku, musiałem rozważyć oba rozwiązania problemu: zarówno szybkie, jak i długoterminowe. I zacząć od tego, co jest krytyczne w tej chwili.

Dzień trzeci

Zatem ładowanie trwa 4 sekundy, a w godzinach od 13 do 15 występują największe szczyty.

Trzeciego dnia w tym przedziale czasowym prędkość ładowania wyglądała tak:

Z mojego punktu widzenia nic nie działało. Z punktu widzenia wszystkich innych wszystko działało nieco wolniej niż zwykle. Ale tak po prostu nie bywa — to poważny problem.

Próbowałem przekonać zespół, ale odpowiedzieli mi, że po prostu potrzebujemy więcej serwerów. Oczywiście, to jest rozwiązanie problemu, ale wcale nie jest jedynym i najskuteczniejszym. Zapytałem, dlaczego brakuje serwerów, jaki jest ruch. Ekstrapolowałem dane i doszedłem do wniosku, że mamy około 150 żądań na sekundę, co w zasadzie mieści się w rozsądnych granicach.

Ale nie można zapominać, że zanim otrzymasz poprawną odpowiedź, musisz zadać właściwe pytanie. Moje następne pytanie brzmiało: ile mamy serwerów front-end. Odpowiedź mnie „lekko zaskoczyła” — mieliśmy 17 serwerów front-end!

— Nie chcę być niemiły, ale 150 podzielić przez 17, to około 8? Mówicie, że każdy serwer obsługuje 8 żądań na sekundę, a jeśli jutro będzie 160 żądań na sekundę, będziemy potrzebować dodatkowych 2 serwerów?

Oczywiście nie potrzebowaliśmy dodatkowych serwerów. Rozwiązanie tkwiło w samym kodzie, i to na powierzchni:

var currentClass = classes.getCurrentClass();
return currentClass;

Była funkcja getCurrentClass(), ponieważ wszystko na stronie działa w kontekście klasy — to prawda. A tylko na tę funkcję na każdej stronie przypadało 200+ żądań.

A zatem rozwiązanie było bardzo proste, nawet nie trzeba było nic przepisywać: po prostu nie należy ponownie żądać tych samych informacji.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Byłem bardzo zadowolony, ponieważ myślałem, że już trzeciego dnia znalazłem główny problem. Jak ja byłem naiwny, to był tylko jeden z wielu problemów.

Jednak rozwiązanie tego pierwszego problemu znacznie obniżyło harmonogram.

Jednocześnie zajmowaliśmy się innymi optymalizacjami. Na powierzchni było wiele rzeczy do naprawienia. Na przykład, trzeciego dnia odkryłem, że w systemie rzeczywiście był cache (początkowo myślałem, że wszystkie zapytania idą bezpośrednio z bazy danych). Gdy myślę o cache, wyobrażam sobie standardowe Redis lub Memcached. Ale tak myślałem tylko ja, ponieważ do cachowania w tym systemie używano MongoDB i SQL Server — tego samego, z którego wcześniej odczytano dane.

Dzień dziesiąty

Pierwszy tydzień zajmowałem się problemami, które musiałem rozwiązać natychmiast. Gdzieś w drugim tygodniu po raz pierwszy przyszedłem na stand-up, aby porozmawiać z zespołem, zobaczyć, co się dzieje i jak przebiega cały proces.

Znowu odkryłem coś interesującego. Zespół składał się z: 18 programistów; 8 testerów; 3 menedżerów; 2 architektów. I wszyscy uczestniczyli w ogólnych rytuałach, to znaczy ponad 30 osób przychodziło na stand-up każdego ranka i mówiło, co robiło. Oczywiście spotkanie nie trwało 5 ani 15 minut. Nikt nikogo nie słuchał, ponieważ wszyscy pracowali na różnych systemach. W tej sytuacji 2-3 zgłoszenia na godzinę podczas sesji groomingowej były już dobrym wynikiem.

Pierwszą rzeczą, którą zrobiliśmy, było podzielenie zespołu na kilka według linii produktów. Dla różnych sekcji i systemów wydzieliliśmy oddzielne zespoły, które obejmowały programistów, testerów, menedżerów produktów oraz analityków biznesowych.

W wyniku tego uzyskaliśmy:

• Skrócenie stand-upów i spotkań.
• Wiedzę merytoryczną o produkcie.
• Poczucie własności. Gdy wcześniej ludzie ciągle rotowali po systemach, wiedzieli, że praca nad ich błędami prawdopodobnie przypadnie komuś innemu, a nie im samym.
• Współpracę między grupami. Nie trzeba mówić, że QA z programistami wcześniej niewiele się komunikowali, a produkt robił swoje. Teraz mieli wspólny punkt odpowiedzialności.

Głównie skupiliśmy się na efektywności, wydajności i jakości — właśnie te problemy chcieliśmy rozwiązać, transformując zespół.

Dzień jedenasty

W trakcie zmiany struktury zespołu odkryłem, jak obliczają HistoriaPunkty. 1 SP odpowiadał jednemu dniu, a każdy tiket zawierał SP zarówno na rozwój, jak i na QA, więc minimum 2 SP.

Jak to odkryłem?

Znaleźliśmy błąd: w jednym z raportów, gdzie wprowadza się datę początkową i końcową okresu, za który potrzebny jest raport, nie uwzględnia ostatniego dnia. To znaczy, że gdzieś w zapytaniu stało nie <=, a po prostu <. Powiedziano mi, że to trzy Story Points, czyli 3 dni.

Po tym zrobiliśmy:

• Przejrzeliśmy system oceny Story Points. Teraz poprawki drobnych błędów, które można szybko przejść przez system, szybciej trafiają do użytkownika.
• Zaczęliśmy łączyć powiązane tickety do rozwoju i testowania. Wcześniej każdy tiket, każdy błąd był zamkniętym ekosystemem, niezwiązanym z niczym innym. Zmiana trzech przycisków na jednej stronie mogła być trzema różnymi tiketami z trzema różnymi procesami QA zamiast jednego automatycznego testu na stronie.
• Zaczęliśmy współpracować z deweloperami nad podejściem do oceny nakładów pracy. Trzy dni na zmianę jednego przycisku — to nie jest śmieszne.

Dzień dwudziesty

W połowie pierwszego miesiąca sytuacja nieco się ustabilizowała, zrozumiałem, co głównie się dzieje, i zacząłem spojrzeć w przyszłość, myśląc o długoterminowych rozwiązaniach.

Cele długoterminowe:

• Zarządzana platforma. Setki zapytań na każdej stronie — to nie jest poważne.
• Przewidywalne trendy. Były okresowe szczyty ruchu, które na pierwszy rzut oka nie korelowały z innymi metrykami — trzeba było zrozumieć, dlaczego tak się dzieje i nauczyć się przewidywać.
• Rozszerzenie platformy. Biznes stale rośnie, przybywa coraz więcej użytkowników, wzrasta ruch.

W przeszłości często mówiono: „Przepiszmy wszystko w [język/rama], wszystko będzie działać lepiej!”

W większości przypadków to nie działa, dobrze, jeśli przepisany kod w ogóle działa. Dlatego musieliśmy stworzyć roadmapę — konkretną strategię, ilustrującą krok po kroku, jak osiągniemy cele biznesowe (co będziemy robić i po co), która:

• odzwierciedla misję i cele projektu;
• priorytetuje kluczowe cele;
• zawiera wykres ich osiągnięć.

Do tej pory nikt nie rozmawiał z zespołem na temat celów, dla których wprowadzane są jakiekolwiek zmiany. Potrzebne są odpowiednie wskaźniki sukcesu. Po raz pierwszy w historii firmy ustaliliśmy KPI dla zespołu technicznego, a te wskaźniki powiązaliśmy z organizacyjnymi.

Oznacza to, że KPI organizacyjne są wspierane przez zespoły, a KPI zespołowe są wspierane już przez indywidualne. W przeciwnym razie, jeśli technologiczne KPI nie zgadzają się z organizacyjnymi, każdy ciągnie w swoją stronę.

Na przykład jednym z KPI organizacyjnych jest zwiększenie udziału w rynku poprzez nowe produkty.

Jak można wspierać cel posiadania większej liczby nowych produktów?

• Po pierwsze, chcemy poświęcać więcej czasu na rozwój nowych produktów zamiast naprawy defektów. To logiczne rozwiązanie, które łatwo zmierzyć.
• Po drugie, chcemy wspierać zwiększenie wolumenu transakcji, ponieważ im większy udział w rynku, tym więcej użytkowników, a co za tym idzie, tym więcej ruchu.

Wtedy indywidualne KPI, które mogą być realizowane w grupie, będą na przykład w obszarze, z którego pochodzą główne defekty. Jeśli skoncentrujemy się na tym obszarze, można sprawić, że defektów będzie znacznie mniej, co z kolei zwiększy czas na rozwój nowych produktów i ponownie na wsparcie KPI organizacyjnych.

W ten sposób każda decyzja, w tym przepisanie kodu, musi wspierać konkretne cele, które firma przed nami postawiła (wzrost organizacji, nowe funkcje, rekrutacja).

W trakcie tego procesu ujawniono ciekawą rzecz, która stała się nowością nie tylko dla techników, ale w całej firmie: wszystkie zgłoszenia muszą być skierowane przynajmniej na jeden KPI. Oznacza to, że jeśli produktowiec mówi, że chce stworzyć nową funkcję, pierwsze pytanie powinno brzmieć: „Jaki KPI wspiera ta funkcja?” Jeśli żaden, to przepraszam — wydaje się, że to zbędna funkcja.

Dzień trzydziesty

Na koniec miesiąca odkryłem kolejny szczegół, że nikt z mojego zespołu Ops nigdy nie widział umów, które zawieramy z klientami. Możesz zapytać, po co widzieć umowy.

• Po pierwsze, ponieważ w umowach zapisane są SLA.
• Po drugie, SLA są różne. Każdy klient przychodził ze swoimi wymaganiami, a dział sprzedaży podpisywał umowy bez sprawdzenia.

Interesującym niuansem jest to, że w umowie z jednym z największych klientów zapisano, że wszystkie wersje oprogramowania wspierane przez platformę powinny być n-1, czyli nie najnowsza wersja, a przedostatnia.

Jasne, jak bardzo byliśmy daleko od n-1, skoro platforma działała na ColdFusion i SQL Serverze z 2008 roku, który w lipcu przestał być wspierany.

Dzień czterdziesty piąty

Gdzieś w połowie drugiego miesiąca miałem wystarczająco dużo czasu, aby usiąść i zrobić valuestreammapping cały proces od początku do końca. To są niezbędne kroki, które należy podjąć, od stworzenia produktu po dostarczenie go do konsumenta, przy czym należy je jak najdokładniej opisać.

Dzieli się proces na małe kawałki i patrzy, co zajmuje zbyt wiele czasu, co można zoptymalizować, poprawić itd. Na przykład, ile czasu zajmuje wnioskowanie od produktu, przechodzenie przez grooming, kiedy trafia do zgłoszenia, które developer może zrealizować, QA itp. Tak szczegółowo analizuje się każdy krok i zastanawia, co można zoptymalizować.

Kiedy to robiłem, rzuciły się w oczy dwie rzeczy:

• wysoki procent zwrotów zgłoszeń z QA z powrotem do programistów;
• przeglądy pull request zajmowały zbyt dużo czasu.

Problem polegał na tym, że były to wnioski typu: wydaje się, że zajmuje dużo czasu, ale nie jesteśmy pewni, ile dokładnie.

„Nie można poprawić tego, czego nie można zmierzyć.”

Jak uzasadnić, jak poważny jest problem? Czy zajmuje on dni, czy godziny?

Aby to zmierzyć, dodano kilka kroków do procesu Jira: „gotowe do dewelopmentu” i „gotowe do QA”, aby mierzyć, ile czasu każde zgłoszenie czeka i ile razy wraca na dany krok.

Dodano również „w recenzji”, aby wiedzieć, ile średnio zgłoszeń przebywa na etapie przeglądu, i od tego już zaczynać. Mieliśmy systemowe metryki, teraz dodaliśmy nowe metryki i zaczęliśmy mierzyć:

• Efektywność procesu: wydajność i zaplanowane/dostarczone.
• Jakość procesu: liczba defektów, błędy z QA.

To naprawdę pomaga zrozumieć, co działa dobrze, a co źle.

Dzień pięćdziesiąty

To wszystko jest oczywiście dobre i interesujące, ale pod koniec drugiego miesiąca zdarzyło się to, co w zasadzie było do przewidzenia, chociaż nie spodziewałem się takiego skali. Ludzie zaczęli odchodzić, ponieważ zmieniło się kierownictwo. Do zarządu przyszli nowi ludzie, którzy zaczęli wszystko zmieniać, a starzy odchodzili. A zazwyczaj w firmie, która istnieje kilka lat, wszyscy są przyjaciółmi i wszyscy się znają.

To było do przewidzenia, ale niespodziewany był skala zwolnień. Na przykład w jednym tygodniu dwóch liderów zespołów jednocześnie złożyło wypowiedzenie. Dlatego musiałem nie tyle zapomnieć o innych problemach, co skupić się na tworzeniu zespołu. To długi i trudny proces, ale trzeba się nim zająć, ponieważ chciałem zatrzymać ludzi, którzy pozostali (lub większość z nich). Należało jakoś zareagować na to, że ludzie odeszli, by podtrzymać morale w zespole.

Teoretycznie to dobrze: przychodzi nowa osoba, która ma pełną swobodę, może ocenić umiejętności zespołu i zastąpić pracowników. W rzeczywistości nie można tak po prostu wprowadzać nowych ludzi z bardzo wielu powodów. Zawsze potrzebny jest balans.

• Starych i nowych. Należy zatrzymać starych ludzi, którzy mogą się zmienić i wspierać misję. Ale jednocześnie trzeba wprowadzić nową krew, o tym porozmawiamy później.
• Doświadczenia. Dużo rozmawiałem z dobrymi juniorami, którzy byli pełni pasji i chcieli do nas do pracy. Ale nie mogłem ich zatrudnić, ponieważ brakowało seniorów, którzy wspieraliby juniorów i byli dla nich mentorami. Najpierw należało nabrać kierownictwa, a dopiero później młodzież.
• Kija i marchewki.

Nie mam dobrego odpowiedzi na pytanie, jaki balans jest właściwy, jak go utrzymywać, ilu ludzi pozostawiać i jak mocno naciskać. To czysto indywidualny proces.

Dzień pięćdziesiąty pierwszy

Zacząłem przyglądać się zespołowi, aby zrozumieć, kogo mam, i po raz kolejny przypomniałem sobie:

„Większość problemów to problemy z ludźmi”.

Odkryłem, że w zespole, zarówno wśród programistów, jak i w Ops, są trzy główne problemy:

• Zadowolenie z obecnego stanu rzeczy.
• Brak odpowiedzialności — ponieważ nikt nigdy nie wiązał wyników pracy wykonawców z wpływem na biznes.
• Lęk przed zmianą.

Zmiany zawsze wyprowadzają z strefy komfortu, a im młodsi ludzie, tym mniej lubią zmiany, ponieważ nie rozumieją, dlaczego i nie wiedzą, jak. Najczęstsza odpowiedź, jaką słyszałem, to: „Nigdy tego nie robiliśmy”. Aż dochodziło do absurdów — najmniejsze zmiany nie przebiegały bez tego, że ktoś nie protestował. I nie miało znaczenia, na ile zmiany dotyczyły ich pracy, ludzie mówili: „Nie, po co? To nie zadziała”.

Ale nie można stać się lepszym, nic nie zmieniając.

Miałem całkowicie absurdalną rozmowę z pracownikiem, mówiłem mu o moich pomysłach na optymalizację, na co on odpowiedział:
— A, nie widziałeś, co mieliśmy w zeszłym roku!
— No i co?
— Teraz jest znacznie lepiej niż było.
— Więc, czy nie może być jeszcze lepiej?
— Po co?

Dobry pytanie — po co? Jakby, jeśli teraz jest lepiej niż było, oznacza to, że wszystko jest wystarczająco dobrze. To prowadzi do braku odpowiedzialności, co w zasadzie jest absolutnie normalne. Jak powiedziałem, grupa techniczna była nieco na uboczu. W firmie uważano, że powinna istnieć, ale nikt nigdy nie ustalał standardów. W wsparciu technicznym nigdy nie widzieli SLA, więc dla grupy było całkiem „akceptowalne” (i to mnie najbardziej zaskoczyło):

• 12 sekund ładowania;
• 5-10 minut przestoju przy każdym wydaniu;
• rozwiązywanie krytycznych problemów zajmowało dni i tygodnie;
• brak dyżurów 24/7 / on-call.

Nikt nigdy nie próbował zapytać, dlaczego nie możemy tego zrobić lepiej, i nikt nigdy nie rozumiał, że tak nie powinno być.

Jako bonus, był jeszcze jeden problem: brak doświadczenia. Starsi odeszli, a pozostający młody zespół wzrósł w dawnym trybie i został nim zatruty.

Do tego ludzie obawiali się ponieść porażkę, wydawać się niekompetentnymi. Objawiało się to tym, że, po pierwsze, nigdy nie prosili o pomoc. Ile razy rozmawialiśmy w grupie i indywidualnie, i mówiłem: „Zadaj pytanie, jeśli nie wiesz, jak coś zrobić”. Jestem pewny siebie i wiem, że mogę rozwiązać każdy problem, ale to zajmie czas. Dlatego jeśli można zapytać kogoś, kto wie, jak to rozwiązać w 10 minut, zapytam. Im mniej masz doświadczenia, tym bardziej boisz się pytać, ponieważ myślisz, że będą cię uważać za niekompetentnego.

Ten lęk przed zadawaniem pytań przybiera interesujące formy. Na przykład pytasz: „Jak idzie ta sprawa?” — „Zostało na parę godzin, już kończę”. Następnego dnia znowu pytasz, dostajesz odpowiedź, że wszystko w porządku, ale pojawił się mały problem, na pewno będzie gotowe do końca dnia. Mija kolejny dzień, a dopóki nie przyciśniesz kogoś do ściany i nie zmusisz do rozmowy, tak to wszystko trwa. Człowiek chce rozwiązać problem sam, uważa, że jeśli sam nie rozwiąże, to będzie to wielka porażka.

Dlatego programiści zawyżali szacunki. To był dopiero dowcip, kiedy omawialiśmy konkretne zadanie, podano mi taką cyfrę, że byłem bardzo zaskoczony. Na co mi powiedziano, że w szacunkach programista uwzględnia także czas, który zajmie powrót tiketu z QA, ponieważ znajdą tam błędy, czas na PR oraz czas, podczas którego osoby, które powinny go sprawdzić, będą zajęte — czyli wszystko, co możliwe.

Po drugie, ludzie, którzy boją się wydać na niekompetentnych, nadmiernie analizują. Kiedy mówisz, co konkretnie trzeba zrobić, zaczyna się: „Nie, a co, jeśli pomyślimy tutaj?”. W tym sensie nasza firma nie jest wyjątkowa, to standardowy problem młodzieży.

W odpowiedzi wprowadziłem następujące praktyki:

• Zasada 30 minut. Jeśli w ciągu pół godziny nie możesz rozwiązać problemu, poproś kogoś o pomoc. Działa to z różnym skutkiem, ponieważ ludzie i tak nie pytają, ale przynajmniej proces się rozpoczął.
• Wyeliminować wszystko, co nie dotyczy sedna, w ocenie czasu realizacji zadania, czyli liczyć tylko to, ile czasu zajmie napisanie kodu.
• Ciągłe uczenie się dla tych, którzy nadmiernie analizują. To po prostu ciągła praca z ludźmi.

Dzień sześćdziesiąty

Gdy tym wszystkim się zajmowałem, nadszedł czas, aby zająć się budżetem. Oczywiście znalazłem wiele interesujących rzeczy w tym, gdzie wydawaliśmy pieniądze. Na przykład mieliśmy całą szafę w osobnym centrum danych, na której stał jeden serwer FTP, używany przez jednego klienta. Okazało się, że „... przeprowadzaliśmy się, a on tak został, nie wymieniliśmy go”. To było 2 lata temu.

Szczególne zainteresowanie wzbudził rachunek za usługi chmurowe. Jestem pewien, że głównym powodem dużego rachunku za usługi chmurowe są programiści, którzy po raz pierwszy w życiu mają nieograniczony dostęp do serwerów. Nie muszą prosić: „Dajcie mi, proszę, serwer testowy”, – mogą je wziąć sami. Do tego programiści zawsze chcą zbudować tak świetny system, żeby Facebook i Netflix im zazdrościły.

Ale programiści nie mają doświadczenia w zakupie serwerów ani umiejętności określenia odpowiedniego rozmiaru serwerów, bo wcześniej nie było to im potrzebne. Zwykle także nie do końca rozumieją różnicę między skalowalnością a wydajnością.

Wyniki inwentaryzacji:

• Wyszło z jednego centrum danych.
• Rozwiązano umowy z 3 usługami logów. Bo mieliśmy ich 5 — każdy programista, który zaczynał coś testować, brał nowy.
• Wyłączono 7 systemów AWS. Znowu, martwe projekty nikt nie zatrzymywał, one dalej działały.
• Zmniejszono wydatki na oprogramowanie sześciokrotnie.

Dzień siedemdziesiąty piąty

Czas mijał, a po dwóch i pół miesiąca miałem spotkać się z radą dyrektorów. Nasza rada dyrektorów nie jest lepsza ani gorsza od innych, jak wszystkie rady dyrektorów chcą wiedzieć wszystko. Ludzie inwestują pieniądze i chcą rozumieć, jak to, co robimy, mieści się w ustalonych KPI.

Rada dyrektorów otrzymuje wiele informacji co miesiąc: liczba użytkowników, ich wzrost, z jakimi usługami korzystają i w jaki sposób, wydajność i produktywność, w końcu średni czas ładowania strony.

Problem tylko w tym, że uważam, że średnia to czyste zło. Ale bardzo trudno jest to wyjaśnić radzie dyrektorów. Przyzwyczaili się operować uśrednionymi danymi, a nie na przykład rozrzutem czasu ładowania w sekundach.

W związku z tym były interesujące momenty. Na przykład powiedziałem, że należy podzielić ruch między poszczególne serwery webowe w zależności od typu treści.

To znaczy, ColdFusion przechodzi przez Jetty i nginx i uruchamia strony. A obrazy, JS i CSS idą przez oddzielny nginx z własnymi konfiguracjami. To dość standardowa praktyka, o której mówiłem napisałem jeszcze kilka lat temu. W rezultacie obrazy ładują się znacznie szybciej i … średni czas ładowania zwiększył się o 200 ms.

To zdarzyło się, ponieważ wykres jest tworzony na podstawie danych, które pochodzą z Jetty. Innymi słowy, szybka zawartość nie jest brana pod uwagę — średnia wartość wzrosła. Rozumieliśmy to, śmialiśmy się, ale jak wyjaśnić radzie dyrektorów, dlaczego zrobiliśmy coś, co pogorszyło sytuację o 12%?

Dzień osiemdziesiąty piąty

Pod koniec trzeciego miesiąca zrozumiałem, że na jedną rzecz w ogóle nie liczyłem — to czas. Na wszystko, o czym mówiłem, potrzeba czasu.

To mój prawdziwy kalendarz na tydzień — po prostu roboczy tydzień, niezbyt obciążony. Czasu na wszystko brakuje. Dlatego znowu musimy zatrudnić ludzi, którzy pomogą poradzić sobie z problemami.

Podsumowanie

To jeszcze nie wszystko. W tej historii jeszcze nawet nie dotarłem do tego, jak pracowaliśmy z produktem i staraliśmy się dopasować do wspólnej fali, czy jak integrowaliśmy wsparcie techniczne, czy jak rozwiązaliśmy inne problemy techniczne. Na przykład, przypadkowo odkryłem, że w największych tabelach w bazie danych w ogóle nie korzystamy SEKWENCJA. Mamy funkcję napisaną przez nas nextID, i używana jest ona nie w transakcji.

Było jeszcze milion podobnych rzeczy, o których można by długo mówić. Ale najważniejsze, o czym warto jeszcze wspomnieć, to kultura.

To właśnie kultura lub jej brak prowadzi do wszystkich innych problemów. Staramy się budować kulturę, w której ludzie:

• nie boją się porażek;
• uczą się na błędach;
• współpracują z innymi zespołami;
• wykazują inicjatywę;
• biorą odpowiedzialność na siebie;
• witam wynik jako cel;
• świetują sukces.

Z tym wszystkim przyjdzie wszystko inne.

Leon Fire na twitterze, facebook i na medium.

Jeśli chodzi o legacy, istnieją dwie strategie: za wszelką cenę unikać pracy z nim lub odważnie pokonywać związane z tym trudności. Posuwamy się DevOpsConf w drugą stronę, zmieniając procesy i podejścia. Dołącz do nas w youtube, newsletterze i Telegramie, a wspólnie wprowadzimy kulturę DevOps.

Źródło: habr.com