Перші 90 днів Senior DevOps в новій компанії. План дій та цілей

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Усім привіт, мене звати Олександр Роздольський, я DevOps Lead і у цій статті хочу поговорити про те, як минають перші робочі дні таких фахівців у новій компанії та поділитись своїми порадами щодо плану дій на перший час.

Коли людей наймають на посаду Senior DevOps або SRE, від них зазвичай очікують, що вони «вирішуватимуть все самі». Тож окрім офіційних процедур онбордингу, ви можете опинитися в ситуації без чіткого плану адаптації.

Якщо такий план і процедура є — вам пощастило, просто продовжуйте роботу. У протилежному випадку, що більш ймовірно, ви можете скласти такий план самостійно. Ось як це може виглядати протягом перших 30, 60 і 90 днів. Цей текст є перекладом моєї статті на Medium.

«Президент Сполучених Штатів має 100 днів, щоб показати себе; у вас є 90 днів. Дії, які ви робитимете протягом перших кількох місяців на новій посаді, значною мірою визначатимуть ваш успіх чи поразку».

Уривок з The First 90 Days, Michael D.Watkins

Перші 30 днів

На цьому етапі дуже важливо зрозуміти загальну картину вашої ситуації та підготувати все для майбутнього значного внеску в компанію.

Дізнайтесь про організаційний та інфраструктурний ландшафт. Щоб зрозуміти структуру команди інженерів, з якою ви працюєте, і те, як виглядає технологічна екосистема, ви можете поставити такі запитання:

1. Чи є схема організаційної структури інженерії? Якщо ні — намалюйте свою. Типи інженерних груп і технічні стеки зазвичай виглядають так:

• Development (Backend/Frontend/Mobile/etc).
• Data (Engineering/Machine Learning/Analytics/Science/etc.).
• Quality Assurance.
• тощо.

2. На якому етапі розвитку DevOps знаходиться організація? Дізнайтеся, які команди Ops/DevOps/SRE/Cloud/NOC присутні та які функції вони виконують.

• Який відтінок DevOps вони представляють?
• Кому вони звітують?
• Які їхні цілі, KPI та активні проєкти?
• Який історичний контекст цих команд?
• Яким чином здійснюється керування безпекою та дозволами?

3. Зрозумійте, як виглядає SDLC:

• Де все розміщується? (cloud/ on-prem/ hybrid)
• Як розгортається? (manual/ automation/ які інструменти/ хто деплоїть)
• Який процес внесення змін (усе зберігається і робляться зміни лише в git/ зміни робляться вручну/ «кастомний» чи гібридний підхід)?
• Як все відстежується? (on-site setup/ saas/ хто моніторить)
• Яка типова повсякденна діяльність різних команд?
• Чи відрізняється SDLC для різних команд?

4. Отримайте практичний досвід. Спробуйте зробити внесок якнайшвидше, а в ідеалі — у різних місцях, так ви найкраще познайомитеся з навколишнім середовищем:

• Створіть PR з незначними змінами.
• Опублікуйте якусь документацію.
• Виправте якісь прості баги.
• Допоможіть усунути несправність.
• І, що важливо, постарайтеся отримати всі доступи до сховища коду тощо та домовтеся про найширші дозволи, можливі на цьому етапі. В кінці місяця у вас буде багато матеріалів і дозволів, якими можна скористатися пізніше.

5. Обговоріть критерії успіху. Поговоріть з керівником, щоб зрозуміти, які критерії успіху для вашої поточної посади. Кілька прикладів влучних запитань, які ви можете поставити:

• Яка причина вашого найму?
• Це заміна чи нова посада, який історичний контекст?
• Чи існує система цілей OKRs/ SMART?
• Чи використовуються системи планування Agile/ Kanban?
• Чи вони відповідають повсякденній роботі, яку ви виконуєте або яку просять виконувати?

6. Фіксуйте інформацію. Це очевидно, але дуже важливо. Ви можете записати все, що дізнаєтесь про нову організацію, і зберегти, щоб потім додати в документацію для організації, що стане додатковою вашою перевагою. Ви можете використовувати будь-яке програмне забезпечення для створення розумових карт або візуалізації, наприклад Excalidraw, AsciiFlow, Lucid або Miro. Ви можете записати відповіді на всі перераховані запитання в будь-якій зручній програмі, наприклад Google Notes, Notion, Obsidian, Evernote або Apple Notes. Пізніше, коли у вас буде більше інформації, ви зможете синтезувати з цього досить хороші результати. Крім того, я заохочую вас почати писати BragDoc, якщо ви цього ще не зробили. Наприкінці місяця матимете ці діаграми та, в ідеалі, дозволи робити що-небудь.

Від 30 до 60 днів

На цьому етапі варто знайти одну потенційну можливість, яка має нераціональне співвідношення зусиль та впливу.

1. Це означатиме, що ви зможете досягти деяких ранніх перемог протягом перших 90 днів, і це принесе величезний ефект. Зазвичай важко знайти таку можливість за короткий період, але мені подобається підходити до ситуації так, щоб ти створював собі таку можливість, а не шукав її. Ось кілька речей, які ви можете зробити:

• Проаналізуйте свою діяльність. Повертаючись до відтінків DevOps, яку саме функцію ви та ваша команда надаєте іншим командам?
• Як ви взаємодієте з іншими командами?
• Ви розгортаєте код?
• Ви виправляєте збірки CI?
• Ви усуваєте проблеми на проді?
• Ви налаштовуєте програми чи допоміжні служби?
• Чи однакова ця функція для різних команд?
• Ви усуваєте неполадки для команди A, автоматизуєте для команди B, відповідаєте на запитання для C, налаштовуєте дозволи для D?
• Які типові запити від цих людей?
• Чи ваша команда та інші команди однаково розуміють вашу функцію?
• Який рівень знань людей в інших командах?
• Вони пишуть код, тестують його, проєктують архітектури чи займаються управлінням проєктами?
• Який рівень їхнього стажу? Чи відповідає це тому, що вони роблять?
• Як вони взаємодіють з DevOps? Чи дотримуються вони принципу «you build it you own it»?

Відповіді на ці запитання допоможуть вам зрозуміти рівень моделі зрілості DevOps в компанії.

2. Подивіться ближче на зовнішню діяльність. Окрім ситуації з впровадженням DevOps, спробуйте звернути увагу на те, що відбувається в компанії загалом.

• Про які high-level проєкти всі говорять?
• Що транслюють люди з Engineering Leadership?
• Якими основними ініціативами займаються різні команди на регулярній основі?
• Які ключові проєкти чи цілі для різних команд?
• Чи відповідає це цілям і діяльності вашої команди?
• Які проблеми виникли протягом перших 30 днів?
• Які типові больові точки описують люди у своїй повсякденній роботі?

3. Порівняйте інформацію із «внутрішніх» та «зовнішніх» джерел і знайдіть «Ага!-момент». Мені подобається ця метафора «Ага!-момент», коли ви можете виявити найвражаючу річ, про яку ніхто раніше не думав. Саме тут у вас виникає відчуття: «Ні в якому разі! З цим можна впоратися набагато краще!». З мого досвіду, такі можливості з’являються в розривах між різними сферами знань/ обов’язків і цілями. На практиці це може бути що завгодно: запровадження нового програмного забезпечення чи інструменту, який вирішує проблеми, розробка простої автоматизації з нуля, яка усуває рутину, або запровадження мінімалістичного редизайну робочого процесу чи процесів. Ось кілька ідей щодо того, як я підходжу до процесу відкриття:

• Спробуйте виділити кількох людей, досягти з ними згоди та зробити їх своїми союзниками.
• Подивіться уважніше на те, що вони роблять і як працюють.
• Намагайтеся ставити відкриті запитання: Яку роботу вони виконують у повсякденній діяльності? Який у них робочий процес і чому? Які у них болі і яких здобутків вони хотіли б досягти?
• Виберіть кілька варіантів, складіть їх у таблицю та спробуйте надати їм ваги.
• Підтвердьте у свого менеджера, що це має сенс.
• Подумайте про те, що ви можете покращити, і забезпечте мінімальне покращення за найкоротший період.
• Спробуйте підтвердити, що ви рухаєтеся в правильному напрямку з кількома людьми, і це узгоджується з різними ініціативами.

Наприкінці другого місяця ви хотіли б мати досить добре розуміння екосистеми, основних гравців та їхні проблеми. В ідеалі ви хотіли б мати чітке розуміння результату, якого ви хочете досягти в короткостроковій перспективі, і одного або двох союзників, які допоможуть вам у цьому.

Від 60 до 90 днів

Це період, який вам знадобиться, щоб переконатися, що у вас є все необхідне, і позбутися блокаторів, аби досягти «перемоги».

1. Розставте пріоритети та заощадьте час для свого нового проєкту.

• Постійно переконуйтеся, що ви на одній хвилі зі своїм керівником.
• Обговоріть додатковий час/ ресурси зі своїм менеджером, якщо вам це потрібно.
• Спробуйте визначити непотрібні заняття, на які ви витрачаєте час, які не наближають вас до мети.

2. Продовжуйте повторювати й отримувати негайний відгук від свого союзника.

• Думайте про концепції історій користувачів, переконайтеся, що робочий процес вашого союзника стає кращим з кожною вашою ітерацією.
• Дотримуйтеся кроків свого союзника самі та спробуйте відчути його UX на власному досвіді.
• Налаштуйте те саме середовище на своєму ноутбуці.
• Переконайтеся, що ви розумієте всі випадки використання.
• Спробуйте внести «фіктивні» зміни, щоб імітувати потік.
• Намагайтеся робити внески якомога частіше найменшими частинами.

3. Презентуйте свою роботу.

• Завершіть проєкт до певної логічної точки, коли ви побачите значний вплив.
• Підготуйте демонстрацію та презентацію разом з вашим союзником для ширшої аудиторії, в ідеалі для всієї інженерної команди.
• Переконайтеся, що ви отримуєте відгуки від багатьох людей з різними точками зору на рішення.
• Зберіть їхні відгуки у своїй демонстрації та отримайте офіційне схвалення.
• Проведіть демонстрацію та зосередьтеся на впливі, коли ви її презентуєте.
• Отримайте зворотний зв’язок після демо і працюйте з ним у своїй подальшій роботі.

Висновок

Якщо ви дотримуєтеся цих вказівок або просто використовуєте деякі з них, є досить високі шанси, що ви зможете створити той початковий імпульс для свого успіху, який ви зможете використовувати пізніше. Це може зайняти понад 90 днів, але, з мого досвіду, це все одно має значення.