11 инструментов для вашего IT бизнеса которые сделают его стабильнее в нестабильное время
Порой случаются события, которые не должны случаться. Мы в “Искусство Автоматизации” за 4 года создания digital-продуктов собрали все из них (ну или те, что касаются IT продуктов). Делимся опытом, инструментами и подходами, которые сделали нашу деятельность стабильнее.
Мы создаем чат-ботов, мобильные приложения, сервисы и сайты. Пишем проекты с нуля, перенимаем проекты от разработчиков, “ушедших в туман”, и за 4 года методом проб и ошибок накопили опыт, которым хотим поделиться с комьюнити. Некоторые уроки покажутся банальными, но от этого не менее важными, особенно в текущей обстановке.
Порой случаются события, которые не должны случаться. Хостинг, на котором располагается проект, ложится на неделю; мобильное приложение снимают с публикации, т.к. не поставили галочку под новой политикой обработки перс. данных; закончилось место на сервере и т.д. И только заказчик звонком в субботу даст о себе знать: «Сайт не открывается, в чем дело?»
Для мониторинга сложных проектов подойдет Zabbix и Datalog. Для проектов поменьше подойдут решения и проще, например, Uptimerobot, с нотификацией в почту, и мобильное приложение.
По нашему опыту, большинство форс-мажоров покрывается мониторингом:
• валидности SSL-сертификата;
• доступности сервиса (HTTP 200);
• телеметрии сервера (свободное место, нагрузка на CPU, загрузка RAM).
И уже первым узнаете о падении вы, а не заказчик.
Мы теряли полностью сервер с проектом, и знаем не понаслышке о шутке про типы системных администраторов. Кто-то возразит: «Нужно было раскошелиться и подключить услугу резервного копирования», но что делать, если учетную запись полностью заблокировали или учредители хостинга выясняют отношения между собой, а все проекты лежат неделю?
Наши выводы:
• скриптом проверять наличие бэкапов, нет бэкапа -> пуш в Telegram-бота;
• исходников в Git недостаточно, бэкапить не только базу, но и код с конфигами;
• шифровать бэкапы;
• раз в N-месяцев проверять сохранность данных, восстанавливаясь из бэкапов.
3. Доступы
Нам доставались проекты по наследству, архитектуру которых мы восстанавливали методом «археологических» раскопок. Кто-то хранит доступы в Google-таблицах, кто-то в Telegram-чатах, а кто-то даже пользуется менеджерами паролей. Мы используем bitwarden.
Для любого digital-проекта важно хранить доступы:
• к серверам (с описанием, какие сервисы запущены на какой машине).
4. Тестовые данные
Если проект состоит из одной посадочной страницы, все рекомендации по тестовому наполнению ограничиваются использованием релевантных текстов и картинок (а не Lorem Ipsum). Но когда речь идет о веб-сервисе, на что обратить внимание:
• сгенерируйте огромное количество данных и узнайте, когда сервис перестанет справляться с нагрузкой, как будет открываться список пользователей если их 2 млн. в базе, когда нужно добавлять индексы на таблицы, пересматривать схему БД и. т.д;
• как выглядят интерфейсы при заполненных данных? Правильно ли отрабатывает пагинация, поиск, верстка на месте?
5. 4хх, 5хх, ххх страницы
Никто не застрахован от 500-х ошибок и падения сервера. Но что видит пользователь в этот момент? Debug-log фреймворка или красивую страницу с «мы знаем что-то сломалось, уже чиним» — зависит от разработчика. Наши рекомендации:
• проверить не включен ли debug-мод на продакшене;
• на этапе тестирования сымитировать 4хх и 5хх ошибки и проверить, что будет видеть пользователь;
• на страницу с ошибкой выводить уникальный ID ошибки, с которым пользователь может обратиться в саппорт и ускорить расследование инцидента.
6. Как выглядит интерфейс под разными учетными записями
При демонстрации проекта заказчику, как правило, демонстрируются позитивные сценарии работы сервиса. При составлении чек-листа тестирования проекта следует учитывать как будет выглядеть интерфейс:
• при частичном заполнении (напр. указаны фамилия, имя, но нет отчества);
• после валидации полей (в правильных ли местах всплывают подсказки).
7. Стресс-тест
Сделали digital-продукт, запустили трафик, проект упал. Было такое? У нас тоже. Как можно было это предусмотреть заранее: провести стресс-тест. Для несложных проектов можно использовать JMeter, для более сложных — поискать облачные решения, например, loader.io.
И вот уже вы знаете, что 500 одновременных подключений сервис выдерживает, 5000 — нет.
В эпоху смартфонов с большой диагональю экрана, все еще остаются пользователи со смартфонами более скромных габаритов.
Необязательно покупать для тестов парк смартфонов, но запустить эмуляцию смартфона и открыть в браузере сервис или мобильное приложение — вполне. Мы так обнаружили, что в приложении на iphone 5s форму регистрации видно, а вот кнопку «Зарегистрироваться» — нет.
Понять оснащенность аудитории помогут логи веб-сервера, в которых, как правило, указывается ОС клиента (по ней можно предположить модель устройства).
Билд готов, протестирован, выкатили на продакшен, посыпались 500-е ошибки. Shit happens. О том, что делать в такой ситуации, можно задуматься заранее и предпринять меры:
• сине-зеленый деплой;
• согласовать релизы на время минимальной нагрузки.
10. Логируемся
С чего начинается разбор полетов? Конечно, с просмотра логов. Слишком подробные логи — плохо, забивается место на диске; логи вида «500 internal server error(точка)» — заставляют грустить разработчика. Наши советы по этому вопросу:
• настроить ротацию логов (логи старше 1 месяца отгружаются на архивный сервер или удаляются);
• добавить в логи ID для каждой ошибки, это упростит общение по всем линиям технической поддержки;
• использовать инструменты менеджмента логов (ELK-стек, Sentry);
• не только логировать бэкенд, но и события на фронте (мы используем Sentry)
11. Дашборды со старта проекта
С самого первого дня digital-продукт генерирует данные, которые хранятся в базах данных. Мы взяли за правило: если есть база данных, она обязательно должна показывать свои данные на дашборд.
В стартовый набор метрик входит:
• динамика регистраций;
• динамика business value actions (кол-во заказов, кол-во транзакции).
Заказчик получает приятный бонус в виде пульс-панели проекта, мы видим прогресс на проекте.
Для преобразований данных используем Airflow. Для построения дашбордов используем Metabase (благо поднимается одной строчкой кода в Docker).
Пишите в комментариях, какие уроки вы нашли полезными, а что я пропустил?