Привіт, Хабре! Десять років я підтримую Highload ІТ-системи. Не буду писати в цій статті проблему налаштування nginx для роботи в режимі 1000+ RPS або інші технічні речі. Поділюсь спостереженнями про проблеми у процесах, що виникають у підтримці та експлуатації таких систем.
моніторинг
Техпідтримка не чекає, поки прилетить заявка зі змістом «Якого Чому… сайт знову не працює?». Підтримка за хвилину після падіння сайту вже має побачити проблему та почати її вирішувати. Але сайт – вершина айсберга. Його доступність ставлять на моніторинг одним із перших.
Як бути із ситуацією, коли залишки товарів інтернет-магазину перестали приходити з ERP системи? Або CRM система, яка розраховує знижки для клієнтів, перестала відповідати? Сайт при цьому на вигляд працює. Умовний Zabbix отримує свою 200 відповідь. Чергова зміна не отримала жодних повідомлень від моніторингу та радісно доглядає першу серію нового сезону «Ігри престолів».
Часто моніторинг обмежується лише вимірюванням стану пам'яті, оперативної пам'яті та навантаженням процесорів серверів. Але для бізнесу набагато важливіше отримати доступність товару на сайті. Умовне падіння однієї віртуальної машини у кластері призведе до того, що трафік перестане на нього йти та зросте навантаження на інші сервери. Гроші компанія не втратить.
Тому, крім моніторингу технічних параметрів операційних систем, на серверах потрібно налаштовувати бізнес-метрики. Метрики, які впливають на гроші. Різні взаємодії із зовнішніми системами (CRM,ERP та інші). Кількість замовлень за певний проміжок часу. Успішні чи не успішні авторизації клієнтів та інші метрики.
Взаємодія із зовнішніми системами
Будь-який сайт або мобільний додаток з річним оборотом більше мільярда рублів взаємодіє із зовнішніми системами. Починаючи від вищезгаданих CRM та ERP і закінчуючи передачею даних про продаж зовнішньої Big Data системі аналізу покупок та пропозиції клієнту товару, який він точно купить (насправді немає). Кожна така система має свою підтримку. І часто спілкування із цими системами викликає біль. Особливо коли проблема глобальна і слід аналізувати їх у різних системах.
Якісь системи дають телефон чи телеграм своїх адмінів. Десь треба писати листи менеджерам чи ходити в баг трекери цих зовнішніх систем. Навіть у межах однієї великої компанії різні системи часто працюють у різних системах обліку заявок. Відстежити статус заявки часом стає неможливо. Ти отримуєш заявку в одній умовній Jira. Потім у коментарі цієї першої Jira ставиш посилання на завдання в іншій Jira. У другій Jira у заявці хтось уже пише коментар, що потрібно зателефонувати умовному адміну Андрію, щоб вирішити питання. І так далі.
Оптимальним варіантом вирішення такої проблеми було б створення єдиного простору для спілкування, наприклад, у Slack. Запрошення до нього всіх учасників процесу експлуатації зовнішніх систем. А також єдиного трекера, щоб не дублювати заявки. Заявки повинні відстежуватися в одному місці, починаючи від оповіщення моніторингу до виведення рішення багів у прод. Ви скажете, що це нереально і у вас так історично склалося, що ми працюємо в одному трекері, а вони в іншому. З'являлися різні системи, вони мали свої автономні ІТ команди. Згодний і тому проблему потрібно вирішувати зверху на рівні CIO чи product owner.
Кожна система, з якою ви взаємодієте, повинна надавати підтримку як послугу з чітким SLA на вирішення пріоритетних проблем. А не тоді коли у умовного адміна Андрія знайдеться вам хвилинка.
Людина-пляшкова шийка
У кожного на проекті (або продукті) є така людина, відпустка якої викликає у начальства судоми? Це може бути devops інженер, аналітик або розробник. Адже тільки devops інженер знає, на яких серверах встановлені якісь контейнери, як перезавантажити контейнер у разі проблеми та й взагалі будь-яка складна проблема без нього не вирішується. Аналітик – єдиний знає, як працює ваш складний механізм. Які потоки даних куди йдуть? При яких параметрах запитів до яких послуг, які ми отримуватимемо відповіді.
Хто швидко зрозуміє чому в логах помилки та оперативно пофіксує критичний баг у проді? Звичайно, цей розробник. Є й інші, але чомусь тільки він розуміє, як влаштовані різні модулі системи.
Коренем цієї проблеми є відсутність документації. Адже якби всі послуги вашої системи були б описані, то можна було б розібратися з проблемою і без аналітика. Якби devops виділив зі свого щільного графіка пару днів і описав би всі сервери, служби та інструкції щодо вирішення типових проблем, то проблему в його відсутності можна було б вирішити і без нього. Не потрібно у відпустці швидко допивати своє пиво на пляжі та шукати wi-fi для вирішення проблеми.
Компетенція та відповідальність співробітників підтримки
На великих проектах компанії не скупляться на зарплату розробникам. Хантять дорогих мідлів чи сеньйорів з аналогічних проектів. З підтримкою ситуація дещо інша. Ці витрати всіляко намагаються скоротити. Компанії наймають недорогих вчорашніх енікейників та сміливо йдуть у бій. Така стратегія можлива, якщо йдеться на сайті-візитці якогось заводу в Зеленограді.
Якщо йдеться про великий інтернет-магазин, то щогодини простою коштує більше ніж місячна зарплата адміна-енікейника. Візьмемо за відправну точку 1 мільярд карбованців річного обороту. Це мінімальний оборот будь-якого інтернет-магазину з рейтингу . Розділимо цю суму на кількість годин на рік і отримаємо понад 100 000 рублів чистих втрат. А якщо не рахувати нічний годинник, то можна сміливо збільшувати суму вдвічі.
Але ж гроші не головне, так? (Ні, звичайно головне) Є ще репутаційні втрати. Час падіння відомого інтернет-магазину може спричинити як хвилю відгуків у соціальних мережах, так і публікації у тематичних ЗМІ. А розмови друзів на кухні у стилі «Не купуй там нічого, у них сайт постійно не працює» взагалі не піддаються вимірам.
Тепер до відповідальності. У моїй практиці був випадок, коли черговий адміністратор вчасно не зреагував на оповіщення системи моніторингу про недоступність сайту. У приємний літній вечір і сайт одного відомого в Москві інтернет-магазину тихо лежав. У суботу вранці продакт цього сайту не зрозумів чому сайт не відкривається, а в чатах підтримки та термінових оповіщень у Slack тиша. Така помилка коштувала нам шестизначну суму, а цьому черговому роботи.
Відповідальність - навик який важко розвинути. Він чи є у людини чи ні. Тому на співбесідах я намагаюся виявити її наявність різними питаннями, які опосередковано показують, чи звикла людина брати відповідальність на себе. Якщо людина відповідає, що вибрала ВНЗ, бо так сказали батьки чи змінює роботу через те, що дружина сказала, що вона мало отримує, то з такими людьми краще не зв'язуватися.
Взаємодія з командою розробки
Коли на продуктивності в процесі експлуатації у користувачів виникають нескладні проблеми, то підтримка вирішує їх самотужки. Намагається відтворити проблему, аналізує логи тощо. Але що робити, коли на проді сплив баг? У цьому випадку підтримка заводить завдання на розробників і тут починається найцікавіше.
Розробники постійно перевантажені. Вони займаються створенням нових фіч. Фіксити баги з прода заняття скажемо не найцікавіше. Горять терміни завершення чергового спринту. А тут приходять неприємні люди з підтримки та кажуть: «Терміново кидай усе, у нас проблеми». Пріоритет таких завдань є мінімальним. Особливо коли проблема не найкритичніша і основний функціонал сайту працює, і коли реліз-менеджер не бігає з витріщеними очима і не пише: «Терміново внести це завдання до найближчого релізу або хотфіксу».
Завдання зі звичайним чи низьким пріоритетом переходять із релізу в реліз. На запитання «Коли завдання буде виконано?» ти отримуватимеш відповіді в стилі: «Пробач, зараз багато завдань, запитай у тих лідів чи реліз менеджера».
Проблеми на продуктивності мають більший пріоритет, ніж створення нових фічів. Погані відгуки не забаряться, якщо користувачі будуть постійно натикатися на баги. Зіпсовану репутацію відновлювати важко.
Питання взаємодії розробки та підтримки вирішує DevOps. Цю абревіатуру часто вживають у вигляді конкретної людини, яка допомагає створювати тестові оточення для розробки, вибудовує пайплайни CICD і швидко виводить протестований код у продакшн. DevOps — підхід до розробки програмного забезпечення, коли всі учасники процесу взаємодіють один з одним і допомагають швидше створювати та оновлювати програмні продукти та послуги. Я маю на увазі аналітиків, розробників, тестувальників та підтримку.
Підтримка та розробка в такому підході не різні відділи зі своїми цілями та завданнями. Розробка залучена в експлуатацію та навпаки. Знаменита фраза розподілених колективів: «Проблема не на моїй стороні» вже не так часто миготить у чатах, і кінцеві користувачі стають щасливішими.
Джерело: habr.com