Wiadomo, że kompetencje CTO są sprawdzane dopiero przy drugim sprawowaniu tej roli. Bo jedną rzeczą jest pracować w firmie kilka lat, ewoluować wraz z nią i będąc w tym samym kontekście kulturowym, stopniowo otrzymywać coraz większą odpowiedzialność. Czym innym jest od razu objęcie stanowiska dyrektora technicznego w firmie z bagażem doświadczeń i mnóstwem problemów zamiatanych pod dywan.

W tym sensie doświadczenie Leona Fire, którym się podzielił Konf. DevOps, nie do końca wyjątkowe, ale pomnożone przez jego doświadczenie i liczbę różnych ról, które udało mu się przymierzyć na przestrzeni 20 lat, jest bardzo przydatne. Poniżej znajduje się chronologia wydarzeń obejmujących 90 dni i wiele historii, z których można się pośmiać, gdy przytrafiają się komuś innemu, ale z którymi nie jest tak fajnie spotkać się osobiście.

Leon bardzo kolorowo mówi po rosyjsku, więc jeśli macie 35-40 minut, polecam obejrzeć film. Wersja tekstowa dla zaoszczędzenia czasu poniżej.

Pierwsza wersja raportu była dobrze ustrukturyzowanym opisem pracy z ludźmi i procesami, zawierającym przydatne rekomendacje. Ale nie przekazała wszystkich niespodzianek, które napotkały po drodze. Dlatego zmieniłem format i przedstawiłem problemy, które pojawiały się przede mną niczym „jack-in-the-box” w nowej firmie, oraz metody ich rozwiązywania w kolejności chronologicznej.

Miesiąc wcześniej

Jak wiele dobrych historii, i ta zaczęła się od alkoholu. Siedzieliśmy ze znajomymi w barze i zgodnie z oczekiwaniami wśród informatyków, wszyscy płakali z powodu swoich problemów. Jeden z nich właśnie zmienił pracę i opowiadał o swoich problemach z technologią, ludźmi i zespołem. Im więcej słuchałem, tym bardziej zdawałem sobie sprawę, że powinien mnie po prostu zatrudnić, ponieważ tego typu problemy rozwiązuję przez ostatnie 15 lat. Powiedziałem mu to i następnego dnia spotkaliśmy się w pracy. Firma nazywała się Teaching Strategies.

Teaching Strategies jest liderem na rynku programów nauczania dla bardzo małych dzieci od urodzenia do trzeciego roku życia. Tradycyjna firma „papierowa” ma już 40 lat, a cyfrowa wersja platformy SaaS 10. Stosunkowo niedawno rozpoczął się proces dostosowywania technologii cyfrowej do standardów firmy. „Nowa” wersja wystartowała w 2017 roku i była prawie taka sama jak stara, tylko działała gorzej.

Najciekawsze jest to, że ruch tej firmy jest bardzo przewidywalny – z dnia na dzień, z roku na rok można bardzo wyraźnie przewidzieć, ile osób przyjdzie i kiedy. Na przykład między 13:15 a XNUMX:XNUMX wszystkie dzieci w przedszkolach idą spać, a nauczyciele zaczynają wprowadzać informacje. I dzieje się tak codziennie, z wyjątkiem weekendów, bo w weekendy prawie nikt nie pracuje.

Patrząc trochę w przyszłość, zauważę, że swoją pracę rozpocząłem w okresie największego rocznego ruchu, który jest interesujący z różnych powodów.

Platforma, która wydawała się mieć zaledwie 2 lata, miała osobliwy stos: ColdFusion i SQL Server z 2008 roku. ColdFusion, jeśli nie wiesz, a najprawdopodobniej nie wiesz, to PHP dla przedsiębiorstw, które pojawiło się w połowie lat 90. i od tego czasu nawet o nim nie słyszałem. Były też: 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 napotkanych problemach, tym bardziej zdawałem sobie sprawę, że problemy nie miały wyłącznie charakteru technicznego. OK, technologia jest stara - i nie pracowali nad nią, ale były problemy z zespołem i procesami, a firma zaczęła to rozumieć.

Tradycyjnie ich technicy siedzieli w kącie i wykonywali jakąś pracę. Jednak coraz więcej biznesów zaczęło korzystać z wersji cyfrowej. Dlatego też w ostatnim roku przed rozpoczęciem pracy w firmie pojawili się nowi: zarząd, dyrektor ds. technologii, dyrektor ds. technologii i kontroli jakości. Oznacza to, że firma zaczęła inwestować w sektorze technologii.

Ślady ciężkiego dziedzictwa znajdowały się nie tylko w systemach. Firma miała starsze procesy, starych ludzi i starą kulturę. To wszystko trzeba było zmienić. Pomyślałam, że na pewno nie będzie nudno i postanowiłam spróbować.

Dwa dni wcześniej

Dwa dni przed rozpoczęciem nowej pracy przybyłem do biura, wypełniłem ostatnie dokumenty, spotkałem się z zespołem i odkryłem, że zespół borykał się wówczas z pewnym problemem. Polegało na tym, że średni czas ładowania strony podskoczył do 4 sekund, czyli 2 razy.

Sądząc po wykresie, coś wyraźnie się wydarzyło i nie jest jasne, co. Okazało się, że problemem były opóźnienia sieci w centrum danych: opóźnienie 5 ms w centrum danych zamieniło się w 2 s dla użytkowników. Nie wiedziałem, dlaczego tak się stało, ale w każdym razie okazało się, że problem dotyczy centrum danych.

Dzień pierwszy

Minęły dwa dni i już pierwszego dnia pracy stwierdziłem, że problem nie zniknął.

Przez dwa dni strony użytkowników ładowały się średnio w 4 sekundy. Pytam, czy znaleźli problem.

- Tak, otworzyliśmy bilet.
- I?
- Cóż, jeszcze nam nie odpowiedzieli.

Wtedy zdałam sobie sprawę, że wszystko, o czym mi wcześniej opowiadano, to tylko wierzchołek góry lodowej, z którą muszę walczyć.

Jest taki dobry cytat, który bardzo dobrze do tego pasuje:

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

Ponieważ jednak zaczynałem pracę w najbardziej pracowitym okresie w roku, musiałem rozważyć obie opcje rozwiązania problemu: szybką i długoterminową. I zacznij od tego, co jest teraz najważniejsze.

Dzień trzeci

Ładowanie trwa więc 4 sekundy, a od 13 do 15 największych szczytów.

Trzeciego dnia w tym okresie prędkość pobierania wyglądała następująco:

Z mojego punktu widzenia nic nie działało. Z punktu widzenia wszystkich innych, działał trochę wolniej niż zwykle. Ale tak się po prostu nie dzieje – to poważny problem.

Próbowałem przekonać zespół, na co odpowiedzieli, że po prostu potrzebują więcej serwerów. Jest to oczywiście rozwiązanie problemu, jednak nie zawsze jedyne i najskuteczniejsze. Zapytałem, dlaczego nie ma wystarczającej liczby serwerów, jakie jest natężenie ruchu. Ekstrapolowałem dane i odkryłem, że mamy około 150 żądań na sekundę, co w zasadzie mieści się w rozsądnych granicach.

Ale nie możemy zapominać, że zanim uzyskasz właściwą odpowiedź, musisz zadać właściwe pytanie. Moje następne pytanie brzmiało: ile mamy serwerów frontendowych? Odpowiedź „trochę mnie zaskoczyła” – mieliśmy 17 serwerów frontendowych!

— wstydzę się pytać, ale 150 podzielone przez 17 daje około 8? Chcesz powiedzieć, że każdy serwer pozwala na 8 żądań na sekundę, a jeśli jutro będzie 160 żądań na sekundę, będziemy potrzebować 2 kolejnych serwerów?

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

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

Była funkcja getCurrentClass(), bo wszystko na stronie działa w kontekście klasy - to prawda. I dla tej jednej funkcji na każdej stronie była Ponad 200 żądań.

Rozwiązanie w ten sposób było bardzo proste, nie trzeba było nawet niczego przepisywać: po prostu nie proś ponownie o te same informacje.

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

Bardzo się ucieszyłem, bo już trzeciego dnia stwierdziłem, że znalazłem główny problem. Choć byłem naiwny, był to tylko jeden z wielu problemów.

Jednak rozwiązanie tego pierwszego problemu obniżyło wykres znacznie niżej.

W tym samym czasie robiliśmy inne optymalizacje. Było wiele rzeczy, które można było naprawić. Na przykład tego samego trzeciego dnia odkryłem, że mimo wszystko w systemie jest pamięć podręczna (początkowo myślałem, że wszystkie żądania pochodzą bezpośrednio z bazy danych). Kiedy myślę o pamięci podręcznej, myślę o standardowym Redis lub Memcached. Ale tylko ja tak myślałem, bo tamten system do buforowania używał MongoDB i SQL Server - tego samego, z którego właśnie odczytano dane.

Dzień dziesiąty

Przez pierwszy tydzień zajmowałem się problemami, które należało rozwiązać już teraz. Gdzieś w drugim tygodniu po raz pierwszy przyszedłem na stand-up, aby porozumieć się z zespołem, zobaczyć, co się dzieje i jak przebiega cały proces.

Znowu odkryto coś interesującego. Zespół składał się z: 18 programistów; 8 testerów; 3 menedżerów; 2 architektów. I wszyscy uczestniczyli we wspólnych rytuałach, czyli każdego ranka na stand-up przychodziło ponad 30 osób i opowiadało, co zrobili. Wiadomo, że spotkanie nie trwało 5 czy 15 minut. Nikt nikogo nie słuchał, bo każdy pracuje na innym systemie. W tej formie 2-3 bilety na godzinę na sesję pielęgnacyjną to już dobry wynik.

Pierwszą rzeczą, którą zrobiliśmy, było podzielenie zespołu na kilka linii produktów. Do poszczególnych sekcji i systemów przydzieliliśmy osobne zespoły, w skład których wchodzili programiści, testerzy, menedżerowie produktu i analitycy biznesowi.

W rezultacie otrzymaliśmy:

• Ograniczenie stand-upów i wieców.
• Wiedza merytoryczna na temat produktu.
• Poczucie własności. Kiedy ludzie bez przerwy majstrowali przy systemach, wiedzieli, że najprawdopodobniej ktoś inny będzie musiał pracować z ich błędami, ale nie oni sami.
• Współpraca między grupami. Nie trzeba dodawać, że dział kontroli jakości nie komunikował się wcześniej zbytnio z programistami, produkt robił swoje itp. Teraz mają wspólny punkt odpowiedzialności.

Postawiliśmy głównie na efektywność, produktywność i jakość – to problemy, które staraliśmy się rozwiązać transformacją zespołu.

Dzień jedenasty

W procesie zmiany struktury zespołu odkryłem, jak liczyć HistoriaPunkty. 1 SP był równy jednemu dniu, a każdy bilet zawierał SP zarówno na rozwój, jak i kontrolę jakości, czyli co najmniej 2 SP.

Jak to odkryłem?

Znaleźliśmy błąd: w jednym z raportów, gdzie wpisana jest data początkowa i końcowa okresu, za który potrzebny jest raport, nie jest brany pod uwagę ostatni dzień. Oznacza to, że gdzieś w żądaniu nie było <=, ale po prostu <. Powiedziano mi, że są to trzy punkty fabularne Dzień 3.

Po tym my:

• System punktacji Story Points został zmieniony. Teraz poprawki drobnych błędów, które można szybko przepuścić przez system, szybciej docierają do użytkownika.
• Zaczęliśmy łączyć powiązane zgłoszenia w celu rozwoju i testowania. Wcześniej każdy bilet, każdy błąd był zamkniętym ekosystemem, niepowiązanym z niczym innym. Zmiana trzech przycisków na jednej stronie mogłaby oznaczać trzy różne zgłoszenia z trzema różnymi procesami kontroli jakości zamiast jednego automatycznego testu na stronę.
• Rozpoczęliśmy współpracę z deweloperami nad podejściem do szacowania kosztów pracy. Trzy dni na zmianę jednego przycisku nie są śmieszne.

Dzień dwudziesty

Gdzieś w połowie pierwszego miesiąca sytuacja trochę się ustabilizowała, zorientowałem się, co się w zasadzie dzieje, i już zacząłem patrzeć w przyszłość i myśleć o długoterminowych rozwiązaniach.

Długoterminowe cele:

• Zarządzana platforma. Setki żądań na każdej stronie nie są poważne.
• Przewidywalne trendy. Występowały okresowe szczyty ruchu, które na pierwszy rzut oka nie korelowały z innymi wskaźnikami – musieliśmy zrozumieć, dlaczego tak się stało i nauczyć się przewidywać.
• Rozbudowa platformy. Biznes stale się rozwija, przybywa coraz więcej użytkowników, a ruch rośnie.

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

W większości przypadków to nie działa, dobrze, jeśli przepisanie w ogóle działa. W związku z tym potrzebowaliśmy stworzenia roadmapy – konkretnej strategii ilustrującej krok po kroku, w jaki sposób cele biznesowe zostaną osiągnięte (co będziemy robić i dlaczego), która:

• odzwierciedla misję i cele projektu;
• priorytetyzuje główne cele;
• zawiera harmonogram ich osiągnięcia.

Wcześniej nikt nie rozmawiał z zespołem na temat celu wprowadzanych zmian. Wymaga to odpowiednich wskaźników sukcesu. Po raz pierwszy w historii firmy wyznaczyliśmy KPI dla grupy technicznej, a wskaźniki te powiązaliśmy z organizacyjnymi.

Oznacza to, że organizacyjne wskaźniki KPI są obsługiwane przez zespoły, a zespołowe wskaźniki KPI są obsługiwane przez indywidualne wskaźniki KPI. W przeciwnym razie, jeśli technologiczne KPI nie pokrywają się z organizacyjnymi, wówczas wszyscy ściągają na siebie koc.

Na przykład jednym z kluczowych wskaźników wydajności organizacji jest zwiększanie udziału w rynku poprzez nowe produkty.

Jak możesz wesprzeć cel, jakim jest posiadanie większej liczby nowych produktów?

• Po pierwsze, chcemy spędzać więcej czasu na opracowywaniu nowych produktów, zamiast naprawiać defekty. Jest to rozwiązanie logiczne i łatwe do zmierzenia.
• Po drugie, chcemy wspierać wzrost wolumenu transakcji, ponieważ im większy udział w rynku, tym więcej użytkowników, a co za tym idzie, większy ruch.

Wtedy poszczególne KPI, które będzie można zrealizować w ramach grupy, znajdą się np. w miejscu, skąd pochodzą główne defekty. Jeśli skoncentrujesz się szczególnie na tej sekcji, możesz mieć pewność, że defektów jest znacznie mniej, a wtedy wydłuży się czas na opracowywanie nowych produktów i ponownie na wspieranie organizacyjnych KPI.

Tym samym każda decyzja, łącznie z przepisaniem kodu, musi wspierać konkretne cele, jakie postawiła przed nami firma (rozwój organizacyjny, nowe funkcje, rekrutacja).

Podczas tego procesu wyszła na jaw ciekawa rzecz, która stała się wiadomością nie tylko dla informatyków, ale w ogóle w firmie: wszystkie bilety muszą być skupione na co najmniej jednym KPI. Oznacza to, że jeśli produkt twierdzi, że chce wprowadzić nową funkcję, należy zadać pierwsze pytanie: „Jakie KPI wspiera ta funkcja?” Jeśli nie, to przepraszam - wydaje się to niepotrzebną funkcją.

Dzień trzydziesty

Pod koniec miesiąca odkryłem kolejny niuans: nikt z mojego zespołu operacyjnego nigdy nie widział umów, które zawieramy z klientami. Możesz zapytać, dlaczego musisz zobaczyć kontakty.

• Po pierwsze dlatego, że SLA są określone w umowach.
• Po drugie, umowy SLA są różne. Każdy klient przyszedł z własnymi wymaganiami, a dział sprzedaży podpisał bez patrzenia.

Kolejnym ciekawym niuansem jest to, że umowa z jednym z największych klientów stanowi, że wszystkie wersje oprogramowania obsługiwane przez platformę muszą być wersją n-1, czyli nie najnowszą, ale przedostatnią.

Jasne jest, jak daleko byliśmy od n-1, jeśli platforma opierała się na ColdFusion i SQL Server 2008, który w lipcu w ogóle nie był już wspierany.

Dzień czterdziesty piąty

Mniej więcej w połowie drugiego miesiąca miałem wystarczająco dużo czasu, aby usiąść i działać wartośćstrumieńmapowanie całkowicie przez cały proces. Są to niezbędne kroki, które należy podjąć, od stworzenia produktu do dostarczenia go konsumentowi, i muszą być opisane możliwie szczegółowo.

Dzielisz proces na małe kawałki i widzisz, co zajmuje zbyt dużo czasu, co można zoptymalizować, ulepszyć itp. Na przykład, ile czasu zajmuje przygotowanie żądania produktu, kiedy dociera do zgłoszenia, które może przyjąć programista, kontroli jakości itp. Dlatego szczegółowo przyglądasz się każdemu etapowi i zastanawiasz się, co można zoptymalizować.

Kiedy to zrobiłem, moją uwagę przykuły dwie rzeczy:

• wysoki odsetek zgłoszeń zwracanych z kontroli jakości do programistów;
• sprawdzanie żądań ściągnięcia trwało zbyt długo.

Problem w tym, że wnioski były takie: Wydaje się, że zajmuje to dużo czasu, ale nie jesteśmy pewni, jak długo.

„Nie możesz ulepszyć tego, czego nie możesz zmierzyć”.

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

Aby to zmierzyć, dodaliśmy do procesu Jira kilka kroków: „gotowy do programowania” i „gotowy do kontroli jakości”, aby zmierzyć, jak długo każdy bilet czeka i ile razy powraca do określonego kroku.

Dodaliśmy także opcję „w trakcie przeglądu”, aby wiedzieć, ile średnio biletów jest do sprawdzenia i na tej podstawie można zacząć tańczyć. Mieliśmy metryki systemowe, teraz dodaliśmy nowe metryki i zaczęliśmy mierzyć:

• Wydajność procesu: wykonanie i zaplanowane/dostarczone.
• Jakość procesu: liczba defektów, defektów z kontroli jakości.

To naprawdę pomaga zrozumieć, co idzie dobrze, a co nie.

Dzień pięćdziesiąty

Wszystko to oczywiście dobre i ciekawe, jednak pod koniec drugiego miesiąca wydarzyło się coś, co w zasadzie było do przewidzenia, choć nie spodziewałem się takiej skali. Ludzie zaczęli odchodzić, bo zmieniło się kierownictwo wyższego szczebla. Do kierownictwa weszli nowi ludzie i zaczęli wszystko zmieniać, a starzy odeszli. I zazwyczaj w firmie, która ma kilka lat, wszyscy się przyjaźnią i wszyscy się znają.

Można było się tego spodziewać, ale skala zwolnień była nieoczekiwana. Przykładowo w ciągu jednego tygodnia dwóch liderów zespołów z własnej woli złożyło jednocześnie rezygnację. Dlatego musiałem nie tylko zapomnieć o innych problemach, ale skupić się na nich tworzenie zespołu. To długi i trudny problem do rozwiązania, ale trzeba było się nim zająć, bo chciałem uratować tych, którzy pozostali (lub większość z nich). Trzeba było jakoś zareagować na odejście ludzi, żeby utrzymać morale w drużynie.

W teorii jest dobrze: przychodzi nowa osoba, która ma pełną kartę blanche, może ocenić umiejętności zespołu i wymienić kadrę. Tak naprawdę z wielu powodów nie można po prostu pozyskać nowych ludzi. Równowaga jest zawsze potrzebna.

• Stare i nowe. Musimy zatrzymać starszych ludzi, którzy mogą się zmienić i wspierać misję. Ale jednocześnie musimy sprowadzić nową krew, porozmawiamy o tym nieco później.
• Doświadczenie. Dużo rozmawiałem z dobrymi juniorami, którzy byli chętni i chcieli z nami pracować. Nie mogłem ich jednak przyjąć, bo nie było wystarczającej liczby seniorów, którzy mogliby wspierać juniorów i pełnić dla nich rolę mentorów. Trzeba było najpierw rekrutować górę, a dopiero potem młodzież.
• Marchewka i patyk.

Nie mam dobrej odpowiedzi na pytanie, czym jest właściwy balans, jak go utrzymać, ile osób utrzymać, a ile naciskać. Jest to proces całkowicie indywidualny.

Dzień pięćdziesiąty pierwszy

Zacząłem uważnie przyglądać się drużynie, aby zrozumieć, kogo mam, i po raz kolejny przypomniałem sobie:

„Większość problemów to problemy ludzi”.

Odkryłem, że zespół jako taki – zarówno Dev, jak i Ops – ma trzy duże problemy:

• Zadowolenie z obecnego stanu rzeczy.
• Brak odpowiedzialności - ponieważ nikt nigdy nie wniósł efektów pracy wykonawców, aby wpłynąć na biznes.
• Strach przed zmianami.

Zmiana zawsze wyprowadza Cię ze strefy komfortu, a im młodsi są ludzie, tym bardziej nie lubią zmian, ponieważ nie rozumieją, dlaczego i nie rozumieją, jak. Najczęstszą odpowiedzią, jaką słyszę, jest: „Nigdy tego nie robiliśmy”. Co więcej, doszło to do zupełnego absurdu – najdrobniejsza zmiana nie mogła nastąpić bez oburzenia. I niezależnie od tego, jak bardzo zmiany wpłynęły na ich pracę, ludzie mówili: „Nie, dlaczego? To nie zadziała.”

Ale nie można stać się lepszym bez zmiany czegokolwiek.

Odbyłem absolutnie absurdalną rozmowę z pracownikiem, przedstawiłem mu swoje pomysły na optymalizację, na co mi odpowiedział:
- Och, nie widziałeś, co mieliśmy w zeszłym roku!
- Więc co?
„Teraz jest znacznie lepiej niż było”.
- Więc nie może być lepiej?
- Po co?

Dobre pytanie – dlaczego? To tak, jakby teraz było lepiej niż było, a potem wszystko było wystarczająco dobrze. Prowadzi to do braku odpowiedzialności, co w zasadzie jest całkowicie normalne. Jak powiedziałem, grupa techniczna była trochę na uboczu. Firma uważała, że ​​powinny istnieć, ale nikt nigdy nie ustalał standardów. Wsparcie techniczne nigdy nie widziało umowy SLA, więc było całkiem „do przyjęcia” dla grupy (i to najbardziej mnie uderzyło):

• Ładowanie 12 sekund;
• 5-10 minut przestoju przy każdej wersji;
• Rozwiązywanie krytycznych problemów zajmuje dni i tygodnie;
• brak personelu dyżurnego 24x7 / dyżur.

Nikt nigdy nie próbował zadać sobie pytania, dlaczego nie zrobimy tego lepiej i nikt nie zdawał sobie sprawy, że nie powinno tak być.

Jako bonus pojawił się jeszcze jeden problem: brak doświadczenia. Seniorzy odeszli, a pozostała młoda drużyna dorastała w poprzednim reżimie i została przez niego otruta.

Do tego wszystkiego ludzie bali się porażki i sprawiania wrażenia niekompetentnych. Wyraża się to w tym, że po pierwsze w żadnym wypadku nie prosił 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 jestem w stanie rozwiązać każdy problem, jednak wymaga to czasu. Dlatego jeśli mogę zapytać kogoś, kto wie, jak to rozwiązać w 10 minut, to zapytam. Im mniej masz doświadczenia, tym bardziej boisz się zapytać, bo myślisz, że zostaniesz uznany za niekompetentnego.

Ten strach przed zadawaniem pytań objawia się w ciekawy sposób. Na przykład pytasz: „Jak sobie radzisz z tym zadaniem?” - „Zostało kilka godzin, już kończę”. Następnego dnia pytasz ponownie, dostajesz odpowiedź, że wszystko w porządku, ale był jeden problem, do końca dnia na pewno będzie gotowe. Mija kolejny dzień i dopóki nie zostaniesz przygwożdżony do ściany i zmuszony do rozmowy z kimś, to trwa. Człowiek chce sam rozwiązać problem, wierzy, że jeśli sam go nie rozwiąże, będzie to wielka porażka.

Właśnie dlatego deweloperzy zawyżyli szacunki. To była ta sama anegdota, kiedy omawiali pewne zadanie, podali mi taką liczbę, że byłem bardzo zaskoczony. Na co powiedziano mi, że w szacunkach dewelopera uwzględnia on czas, w którym bilet zostanie zwrócony z kontroli jakości, ponieważ znajdą tam błędy, oraz czas, jaki zajmie PR, i czas, w którym osoby powinny sprawdzić będzie zajęty - czyli wszystkim, czymkolwiek się da.

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

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

• Zasada 30 minut. Jeśli nie możesz rozwiązać problemu w pół godziny, poproś kogoś o pomoc. Działa to z różnym skutkiem, ponieważ ludzie nadal nie pytają, ale przynajmniej proces się rozpoczął.
• Wyeliminuj wszystko oprócz esencji, szacując termin wykonania zadania, czyli bierz pod uwagę jedynie to, ile czasu zajmie napisanie kodu.
• Kształcenie ustawiczne dla tych, którzy nadmiernie analizują. To po prostu ciągła praca z ludźmi.

Dzień sześćdziesiąty

Kiedy to wszystko robiłem, przyszedł czas na ustalenie budżetu. Oczywiście znalazłem wiele ciekawych rzeczy w tym, gdzie wydaliśmy nasze pieniądze. Przykładowo mieliśmy całą szafę w osobnym centrum danych z jednym serwerem FTP, z którego korzystał jeden klient. Okazało się, że „...przeprowadziliśmy się, ale on tak pozostał, nie zmieniliśmy go”. To było 2 lata temu.

Szczególnie interesujący był projekt ustawy o usługach w chmurze. Uważam, że głównym powodem wysokich rachunków za chmurę są programiści, którzy po raz pierwszy w życiu mają nieograniczony dostęp do serwerów. Nie muszą pytać: „Proszę, daj mi serwer testowy”, mogą sami go wziąć. Poza tym programiści zawsze chcą zbudować tak fajny system, że Facebook i Netflix będą zazdrosne.

Ale programiści nie mają doświadczenia w zakupie serwerów i umiejętności określania wymaganej wielkości serwerów, ponieważ wcześniej tego nie potrzebowali. I zazwyczaj nie do końca rozumieją różnicę między skalowalnością a wydajnością.

Wyniki inwentaryzacji:

• Opuściliśmy to samo centrum danych.
• Rozwiązaliśmy umowę z 3 usługami logowania. Ponieważ mieliśmy ich 5 - każdy programista, który zaczął się z czymś bawić, brał nowego.
• Zamknięto 7 systemów AWS. Ponownie nikt nie zatrzymał martwych projektów; wszystkie kontynuowały pracę.
• Zmniejszono koszty oprogramowania 6-krotnie.

Dzień siedemdziesiąty piąty

Czas mijał i za dwa i pół miesiąca musiałem spotkać się z zarządem. Nasz zarząd nie jest lepszy ani gorszy od innych; jak wszystkie zarządy, chce wiedzieć wszystko. Ludzie inwestują pieniądze i chcą zrozumieć, na ile to, co robimy, wpisuje się w wyznaczone KPI.

Zarząd co miesiąc otrzymuje wiele informacji: liczbę użytkowników, ich rozwój, z jakich usług i w jaki sposób korzystają, wydajność i produktywność, czy wreszcie średnią prędkość ładowania strony.

Jedynym problemem jest to, że uważam, że przeciętność jest czystym złem. Ale bardzo trudno jest to wyjaśnić zarządowi. Są przyzwyczajeni do operowania liczbami zagregowanymi, a nie np. rozłożeniem czasów ładowania na sekundę.

Było w tym względzie kilka interesujących punktów. Powiedziałem na przykład, że musimy podzielić ruch pomiędzy oddzielne serwery internetowe w zależności od rodzaju treści.

Oznacza to, że ColdFusion przechodzi przez Jetty i Nginx i uruchamia strony. A obrazy, JS i CSS przechodzą przez osobny nginx z własnymi konfiguracjami. To dość standardowa praktyka, o której mówię pisałem kilka lat temu. W rezultacie zdjęcia ładują się znacznie szybciej, a... średnia prędkość ładowania wzrosła o 200 ms.

Stało się tak, ponieważ wykres jest zbudowany w oparciu o dane dostarczane z Jetty. Oznacza to, że szybka zawartość nie jest uwzględniana w obliczeniach - średnia wartość wzrosła. To było dla nas jasne, śmialiśmy się, ale jak wytłumaczyć zarządowi, dlaczego coś zrobiliśmy i sytuacja pogorszyła się o 12%?

Dzień osiemdziesiąty piąty

Pod koniec trzeciego miesiąca uświadomiłam sobie, że na jedną rzecz w ogóle nie liczyłam: czas. Wszystko, o czym mówiłem, wymaga czasu.

To jest mój prawdziwy kalendarz tygodniowy - po prostu tydzień roboczy, niezbyt zajęty. Na wszystko nie starcza czasu. Dlatego po raz kolejny musisz zrekrutować ludzi, którzy pomogą Ci uporać się z problemami.

wniosek

To nie wszystko. W tej historii nawet nie doszedłem do tego, jak pracowaliśmy z produktem i próbowaliśmy dostroić się do ogólnej fali, jak zintegrowaliśmy wsparcie techniczne lub jak rozwiązaliśmy inne problemy techniczne. Zupełnie przez przypadek dowiedziałem się, że na największych tabelach w bazie danych nie korzystamy SEQUENCE. Mamy samodzielnie napisaną funkcję nextIDi nie jest używany w transakcji.

Podobnych rzeczy było jeszcze milion, o których moglibyśmy długo rozmawiać. Ale najważniejszą rzeczą, o której trzeba jeszcze powiedzieć, jest kultura.

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

• nie boją się niepowodzeń;
• Ucz się na błędach;
• współpracować z innymi zespołami;
• przejąć inicjatywę;
• brać odpowiedzialność;
• powitaj wynik jako cel;
• świętować sukces.

Dzięki temu wszystko inne nadejdzie.

Leon Ogień na Twitterze, na facebooku i średni.

Istnieją dwie strategie dotyczące dziedzictwa: unikaj pracy z nim za wszelką cenę lub odważnie pokonuj związane z nim trudności. my c Konf. DevOps Podążamy drugą ścieżką, zmieniając procesy i podejścia. Dołącz do nas na youtube, Lista mailingowa и telegrami wspólnie wdrożymy kulturę DevOps.

Źródło: www.habr.com