Збіги випадкові, та й взагалі це було на іншій планеті.
Хочу поділитися трьома історіями успіху та неуспіху про те, як працює бекенд розробнику в команді з адмінами.
Історія перша.
Веб-студія, кількість співробітників піддається рахунку однією рукою. Сьогодні ти верстальник, завтра бекендер, післязавтра адмін. З одного боку, можна здобути колосальний досвід. З іншого боку, не вистачає компетенції у всіх областях. Досі пам'ятаю перший робочий день, я ще зелений, начальник каже: Відкривай putty, а я не знаю, що це таке. Спілкування з адмінами виключено, т.к. ти сам адмін. Розглянемо плюси та мінуси такого положення.
+ Вся влада в твоїх руках.
+ Не потрібно ні в кого клянчити доступи від сервера.
+ Швидкий час реакції у всіх напрямках.
+ Добре прокачує скіли.
Є повне розуміння архітектури продукту.
- Висока відповідальність.
- Ризик поламати продакшен.
— Важко бути добрим фахівцем у всіх областях.
Не цікаво, чи йдемо далі
Історія друга.
Велика компанія, великий проект. Є відділ адміністрування з 5-7 співробітниками та кілька груп розробки. Коли приходиш працювати в таку компанію, кожен адмін вважає, що ти прийшов сюди не працювати над продуктом, а щось зламати. Ні підписане NDA, ні відбір на співбесіді не говорить про інше. Ні, ця людина прийшла сюди своїми брудними ручками зіпсувати наш цілований продакшен. Тому з такою людиною потрібно мінімум спілкування, на крайняк можна кинути наклейку у відповідь. На питання щодо архітектури проекту не відповідати. Бажано не видавати доступи доки тимлід не попросить. А коли попросить, видати з ще меншими привілеями, ніж просили. Практично вся комунікація з такими адмінами поглинається чорною діркою між відділом розробки та відділом адміністрування. Вирішити питання оперативно неможливо. А підійти особисто не можна – адміни надто зайняті 24/7. (Чим ви постійно зайняті?) Деякі ТТХ:
- Середній час деплою у продакшен 4-5ч
- Максимальний час деплою у продакшен 9ч
- Для розробника додаток у продакшені це чорна скринька, як і сам сервер продакшену. А скільки їх загалом?
- Низька якість релізів, часті помилки
- Розробник не бере участі у процесі релізу
Ну а що я чекав, звичайно, на продакшен новеньких не пускають. Ну та гаразд, набравшись терпіння починаємо отримувати довіру у оточуючих. Але чомусь із адмінами не все так просто.
Акт 1. Адмін невидимка.
День релізу, розробник та адмін не спілкуються. Адмін не має жодних питань. Але чомусь розумієш пізніше. Адмін важлива особа, не має месенджерів, номер телефону нікому не дає, профілю в соцмережах не має. Та навіть його фото ніде немає, як ти виглядаєш чувак? Сидимо з відповідальним менеджером хвилин 15 здивовано, намагаємося налагодити зв'язок із цим «Вояджер-1», тут на корпоративну пошту падає повідомлення, що він закінчив. Ми що поштою листуватимемося? А чому б ні? Зручно, чи не так? Ну та гаразд, охолонемо. Процес уже йде, тому дороги немає. Читаємо ще раз повідомлення. "Я закінчив". А що ти закінчив? Де? Куди дивитися, щоб тебе? Тут ви знаєте, чому 4ч на реліз це нормально. Отримуємо шок, але реліз закінчуємо. Бажання релізу більше немає.
Акт 2. Чи не та версія.
Ще один реліз. Набравшись досвіду, ми починаємо формувати списки необхідного софту та бібліотек на сервер для адмінів, із зазначенням версій для деяких. Як завжди, отримуємо слабкий радіосигнал, що адмін щось там закінчив. Починається регресійний тест, який сам собою займає близько години. Начебто все працює, але є один критичний баг. Важлива функціональність не працює. Наступні кілька годин танці з бубнами, ворожіння на кавовій гущі, детальний перегляд кожного шматка коду. Адмін каже, що все зробив. Не працює ж програма написана криворукими розробниками, а сервер працює. Які щодо нього питання. Наприкінці якоїсь години таки добиваємося від адміна, щоб той скинув у чат версію бібліотеки на продакшен сервері та бінго — вона не та, що потрібна. Просимо адміна поставити потрібну версію, у відповідь отримуємо, що він цього зробити не може через відсутність цієї версії в пакетному менеджері ОС. Тут із засіків пам'яті менеджер згадує, що інший адмін вже вирішував цю проблему, просто зібравши потрібну версію руками. Але ні, наш цього робити не стане. Регламент забороняє. Карл ми вже кілька годин сидимо, який регламент? Отримуємо черговий шок, реліз абияк закінчуємо.
Акт 3, короткий
Терміновий тикет, на продакшені не працює ключовий функціонал одного з користувачів. Кілька годин тикаємо, перевіряємо. У девелоп середовищі все працює. Є чітке розуміння, що непогано зазирнути в логи php-fpm. Системи для логів на кшталт ELK чи Prometheus на проекті не було. Заводимо тикет на відділ адміністрування, щоб дали доступ до логів php-fpm на сервер. Тут треба розуміти, що доступ просимо не просто, ви ж пам'ятаєте про чорну дірку і зайнятість адмінів 24/7? Якщо попросити їх подивитися логи самим, це завдання з пріоритетом «не в цьому житті». Тикет створений, отримуємо миттєву відповідь від голови відділу адміністрування: «Вам не повинен бути потрібний доступ до логів на продакшені, пишіть без багів». Завіса.
Акт 4 та наступні
Збираємо ще жоден десяток проблем на продакшені, через різні версії бібліотек, не налаштованого, непідготовленого до навантажень сервера та інших проблем. Кодові баги звичайно теж бувають, не у всіх гріхах звинувачуватимемо адмінів, згадаємо тільки ще одну типову операцію для того проекту. Було у нас чимало фонових воркерів, які запускалися через супервізор, а деякі скрипти треба було додавати до cron. Іноді ці воркери переставали працювати. На сервері черг блискавично зростало навантаження, а сумні користувачі дивилися на лодер, що крутився. Для швидкого ремонту такі воркери досить було просто перезапустити, але знову ж таки зробити це міг тільки адмін. Поки що така елементарна операція виконувалася міг пройти цілий день. Тут звичайно варто відзначити, що криворукі програмісти повинні писати воркери так щоб вони не падали, але коли вони впали, непогано б розуміти чому, що іноді неможливо через відсутність доступів на продакшен звичайно ж і як наслідок відсутність логів у розробника.
Перетворення.
Потерпівши це все досить тривалий час, разом із командою ми почали кермувати у успішніше нам русло. Якщо резюмувати які перед нами стояли проблеми?
- Відсутність якісної комунікації між розробниками та відділом адміністрування
- Адміни, виявляється(!), зовсім не розуміють, як влаштовано додаток, які в нього залежності і як він працює.
- Розробники не розуміють, як влаштовано продакшене середовище і як наслідок не можуть ефективно реагувати на проблеми.
- Занадто тривалий час займає процес деплою.
- Нестабільні релізи.
Що ми зробили?
До кожного релізу формували список Release Notes, який включав перелік робіт, які необхідно провести на сервері, для чергового релізу. Список містив кілька секцій, роботи, які має провести адміністратор, відповідальний за реліз та розробник. Розробники отримали доступ (не root) на всі продакшен сервери, що прискорило розробку в цілому та вирішення проблем зокрема. Так само у розробників з'явилося розуміння як влаштований продакшен, на які послуги поділено, де і скільки коштує реплік. Від частини стали зрозуміліші бойові навантаження, що безсумнівно впливає якість коду. Спілкування у процесі релізу відбувалося у чаті одного з месенджерів. По-перше, у нас з'являвся лог всіх дій, по-друге, спілкування відбувалося в тіснішому середовищі. Наявність історії дій жодного разу дозволяло новим співробітникам швидше вирішити проблеми. Парадокс, але це найчастіше допомагало самим адмінам. Я не буду стверджувати точно, але мені здається, що адміни стали більше розуміти, як влаштований проект, як він написаний. Іноді ми навіть ділилися деякими деталями. Середній час релізу скоротився до години. Іноді ми укладалися за 30-40 хвилин. Кількість багів скоротилася у рази, якщо не в десятки разів. Звичайно, на скорочення часу релізу впливали й інші фактори, наприклад, такі як автотести. Після кожного релізу ми почали проводити ретроспективи. Щоб вся команда мала уявлення, що нового з'явилося, що змінилося, а що було прибрано. На жаль, адміни далеко не завжди на них приходили, ну адміни ж зайняті… Задоволеність роботою у мене, як у розробника, безперечно підвищилася. Коли ти можеш швидко вирішити практично будь-яку проблему, яка в твоїй зоні компетенції, ти почуваєшся на коні. Пізніше, я зрозумію, що ми якоюсь мірою впровадили девопс культуру, не цілком звичайно, але навіть початок трансформації був вражаючим.
Історія третя
Стартап. Один адмін, невеликий відділ розробників. По приходу повний нуль, т.к. окрім як від пошти доступів у мене нікуди немає. Пишемо адміну, просимо надати доступи. До того ж є інформація, що він в курсі, нового співробітника та необхідності у видачі логінів/паролів. Дають доступ від репозиторію та впн. Навіщо давати доступи до wiki, teamcity, rundesk? Некорисні речі для людини, яку покликали повністю писати бекенд частину. Лише згодом отримуємо доступ до деяких інструментів. Парафія, звичайно, зустріла недовіру. Пробую потихеньку промацати як влаштована інфраструктура проекту через чати та питання. Здебільшого нічого не впізнаю. Продакшена така ж чорна скринька, як і раніше. Але більше того, тут чорна скринька навіть stage сервера, що використовуються для тестування. Окрім деплою туди гілки з гіта, ми нічого не можемо. Також ми не можемо конфігурувати свою програму на кшталт .env файлів. Доступ до таких операцій не покладено. Треба займатися попрошайництвом, щоб тобі поміняли рядок у конфізі твого додатка на тестовому сервері. (Є теорія, що адмінам життєво необхідно почуватися найважливішими на проекті, якщо їх не проситимуть змінювати рядки в конфігах, вони просто будуть не потрібні). Ну як завжди, чи не так зручно? Таке швидко набридає, після прямої розмови з адміном з'ясовуємо, що розробники народилися для того, щоб писати поганий код, за своєю природою некомпітентні особи і краще їх тримати подалі від продакшена. Але тут ще й від тестових серверів про всяк випадок. Конфлікт швидко набирає обертів. Комунікації з адміном немає. Ситуація посилюється тим, що вона одна. Далі — типова картина. Реліз. Чи не працює певний функціонал. Довго розуміємось у чому справа, в чат накидаються різні ідеї від розробників, але адмін у такій ситуації зазвичай виходить, що винні розробники. Потім пише в чаті, стійте я поправив. На прохання залишити історію після себе з інформацією, в чому була проблема, отримуємо токсичні відмовки. Мовляв, не суй свій ніс куди не треба. Розробники мають писати код. Ситуація, коли багато рухів тіла в проекті проходять через одну єдину людину і тільки в нього є доступи для здійснення потрібних всім операцій вкрай сумна. Така людина жахлива пляшка. Якщо ідеї Devops прагнуть скоротити time-to-market, то такі люди це найлютіший ворог ідей devops'a. На жаль, тут закривається завіса.
PS Трохи поспілкувавшись на тему розробники проти адміни в чатах з людьми, я зустрів людей, які розділили мій біль. Але також були ті, хто сказав, що з таким не стикався. На одній devops конференції я поцікавився у Антона Ісаніна (Альфа-банк), як вони боролися з проблемою пляшкового шийки у вигляді адмінів, на що він сказав: «Ми їх замінили на кнопки». Ось до речі за його участю. Хочеться вірити, що добрих адмінів набагато більше ніж ворогів. І так, картинка на початку це реальне листування.
Джерело: habr.com