Адміністрування

Як стати найгіршим DevOps-інженером: 9 кроків до краху

Крутий DevOps: який він? Цей спеціаліст майстерно налаштовує інфраструктури, автоматизує та створює конвеєри краще за Генрі Форда, а його комунікаційні навички оцінять навіть досвідчені менеджери з продажів. Він знає, як покращити процеси та подружити Dev та Ops. Для цього поєднує сильні хард та софт скіли.

Ми неодноразово писали у блозі про те, як стати таким фахівцем. Проте, що може призвести до невдачі?

Метод проб та помилок чудово допомагає засвоїти, як робити не треба, але ми хочемо зекономити твій час. Тож поїхали — розгляньмо 9 помилок, які неодмінно приведуть до винагороди «Золота малина» у DevOps.

#1. Забути про культуру

Не треба готувати команду до впровадження DevOps. Не варто пояснювати, навіщо це потрібно та як від цього виграє і команда, і бізнес. 

Колегам не потрібно вчитися працювати із фідбеками, ефективно комунікувати зі спеціалістами інших ІТ-спеціальностей та розв’язувати конфлікти, які неодмінно з’являться. Не треба виділяти час на адаптацію до змін. Згадай, як раніше дітей вчили плавати: кинули у воду і дивляться, чи випливе. Це працювало раніше, працює й досі.

Краса DevOps у тому, що кожен може розуміти цю методологію по-своєму. Розробники можуть бачити її як новий підхід до створення ПЗ за допомогою інших інструментів на кшталт Chef, Puppet, Jenkins, Git або Docker. А команда з експлуатації розглядатиме DevOps з точки зору покращення процесів та фокусуватиметься на швидшому виході на ринок. І добре, має ж залишитися якась таємниця.

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

#2. Бійся помилок

Пошук нових ідей — не для DevOps-інженерів, це для творчих професій. Інновації завжди йдуть пліч-о-пліч з ризиками. Ці зміни можуть бути невдалими, тож краще нічого не чіпати та залишити, як є. 

Навіть якщо всі навколо кажуть, що інструменти на проєкті вже застарілі та неефективні — не ведись. Не дай їм збити себе зі шляху.

#3. Нічого не автоматизуй

Автоматизація — для слабаків. Команда не розумітиме, як відбуваються процеси, якщо не робитиме все самостійно. Ручні процеси допомагають повністю зануритися в розробку продукту. Тут присутній людський фактор, тож можуть виникати помилки, наприклад, під час збирання застосунку. Але все це — досвід.

Так, користувачі отримають продукт пізніше, але знатимуть, що команда виклалась на повну на кожному етапі. А це особливо цінно.

Також не радимо автоматизувати процеси розгортання та управління конфігураціями. Так команда зовсім розслабиться і буде займатися покращенням продукту, а не повторюваними задачами. Так і до інновацій недалеко!

#4. Підтримуй розділення команд 

Навіщо командам взаємодіяти, якщо кожен і без того знає свою зону відповідальності та обов’язки? Розробники пишуть код, QA-спеціалісти тестують розроблене ПЗ, адміністратори його розгортають. Співпраця, синхронізаційні дзвінки, якісь ретро коли — вигадки людей, які готові на все, аби не працювати.

Діяти як одна організована команда з орієнтацією на спільний результат навіть звучить надто казково. В реальності всі команди зосереджуються лише на тому, що їм потрібно. Всі розв’язують власні проблеми у своїх командах. Тому DevOps намагається об’єднати їх. Але раптом не вийде? (Дивись помилку #2)

#5. Не треба нічого моніторити

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

Щось впаде — піднімемо. Проблеми варто розв’язувати в міру їх надходження.

Моніторинг допомагає на ранніх етапах виявляти проблеми, загрози безпеці та вразливі місця у режимі реального часу. Це дозволяє розв’язувати проблеми до того, як вони стануть критичними. Також моніторинг надає важливу інформацію щодо продуктивності системи, що допоможе оптимізувати використання ресурсів та підвищити продуктивність. Але це для тих, хто шукає легкі шляхи.

#6. Кому потрібна безпека?

Ми ще розуміємо, якщо ти працюєш в Apple, Microsoft чи іншій відомій великій компанії. Але й в такому випадку це не головне.

Коли працюєш з невеликим локальним бізнесом, безпека — робота заради роботи. Нікому не цікаві дані твоїх користувачів. Та й кому потрібні сильні паролі, якщо є password або qwerty, які зламують менш як за 1 секунду.

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

Щось із паралельної реальності: середня вартість витоку даних у США у 2023 році складає $9,45 млн. Якщо дивитися на глобальний ринок, то цей показник складає $4,45 млн. 

#7. Забудь про документацію

Документація — небезпечна для кар’єри. Якщо всю інформацію тримаєш у голові, ти автоматично стаєш незамінним співробітником. Не документуй процеси, конфігурації та будь-які зміни в інфраструктурі. Хай всі знають, що з будь-якими питаннями треба йти до тебе.

Хтось може сказати, що документація важлива для ефективної співпраці, обміну знаннями, усунення несправностей та онбордингу нових членів команди. Словом, пусті балачки. Ці люди, певно, нічого не знають про DevOps.

#8. Впровадження DevOps заради DevOps

Amazon, Netflix та Google впровадили DevOps та активно розвивають цей напрям. Вони відмічають, що завдяки методології їхні результати стали ще кращими. Висновок напрошується сам собою: хочеш бути успішним — впровадь DevOps.

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

Все найкраще вже зробили до нас. Просто візьми досвід тої компанії, що подобається більше, наприклад, Netflix. Застосуй ті самі інструменти на своєму проєкті. Навіть якщо проєкт не працює з величезними масивами даних або не займається стрімінгом — неважливо. Головне, ти впровадиш DevOps!

#9. Думай тільки про інструменти

Ця методологія зовсім не про культуру, він про інструменти. Додай на проєкт кілька модних інструментів, наприклад, Docker, Kubernetes та Terraform, і готово.

Хтось скаже, що DevOps — це суміш культури, процесів та інструментів. І інструменти допомагають забезпечити та підтримати інші дві складові. Насправді саме тули визначають успіх впровадження методології, просто інші не хочуть цього визнавати. 

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

Замість висновку: ускладнюй все!

Для того, щоб досягти успіху у будь-якій справі, потрібно ставити собі правильні цілі. 

Якщо дотримуватися нескладних правил, які ми описали у цій статті, ти неодмінно станеш найгіршим DevOps-інженером. 

Роби кожний процес максимально складним. Хай вони будуть заплутаними та незрозумілими. Пам’ятай, робота в ІТ — це біль та страждання.

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

Зроби своїм девізом «Ні оптимізації!». Нехай системи будуть повільними та неефективними. Тоді ти точно отримаєш потрібний результат та отримаєш звання найгіршого DevOps-інженера.

Йди до мети! Стати найгіршим або успішним DevOps-інженером — обирати тобі. Якщо все ж, хочеш спробувати себе у другому сценарії — реєструйся на курси IT Education Center. Ти отримаєш багато теорії, практичні навички, актуальні технології у стек та впевненість у своїх силах. Переходь за посиланням вище та обирай потрібний курс. Або ж напиши у коментарях «Консультація» та перевіряй пошту. Ми неодмінно з тобою зв’яжемося та допоможемо спланувати навчання.