11 инструментов для вашего IT бизнеса которые сделают его стабильнее в нестабильное время

Мы создаем чат-ботов, мобильные приложения, сервисы и сайты. Пишем проекты с нуля, перенимаем проекты от разработчиков, «ушедших в туман», и за 4 года методом проб и ошибок накопили опыт, которым хотим поделиться с комьюнити. Некоторые уроки покажутся банальными, но от этого не менее важными, особенно в текущей обстановке.

1. Мониторинг

Порой случаются события, которые не должны случаться. Хостинг, на котором располагается проект, ложится на неделю; мобильное приложение снимают с публикации, т.к. не поставили галочку под новой политикой обработки перс. данных; закончилось место на сервере и т.д. И только заказчик звонком в субботу даст о себе знать: «Сайт не открывается, в чем дело?»

Для мониторинга сложных проектов подойдет Zabbix и Datalog. Для проектов поменьше подойдут решения и проще, например, Uptimerobot, с нотификацией в почту, и мобильное приложение.

По нашему опыту, большинство форс-мажоров покрывается мониторингом:

• валидности SSL-сертификата;

• доступности сервиса (HTTP 200);

• телеметрии сервера (свободное место, нагрузка на CPU, загрузка RAM).

И уже первым узнаете о падении вы, а не заказчик.

2. Бэкапы

Мы теряли полностью сервер с проектом, и знаем не понаслышке о шутке про типы системных администраторов. Кто-то возразит: «Нужно было раскошелиться и подключить услугу резервного копирования», но что делать, если учетную запись полностью заблокировали или учредители хостинга выясняют отношения между собой, а все проекты лежат неделю?

Наши выводы:

• бэкапить проект у разных хостинг-провайдеров;

• скриптом проверять наличие бэкапов, нет бэкапа -> пуш в Telegram-бота;

• исходников в Git недостаточно, бэкапить не только базу, но и код с конфигами;

• шифровать бэкапы;

• раз в N-месяцев проверять сохранность данных, восстанавливаясь из бэкапов.

3. Доступы

Нам доставались проекты по наследству, архитектуру которых мы восстанавливали методом «археологических» раскопок. Кто-то хранит доступы в Google-таблицах, кто-то в Telegram-чатах, а кто-то даже пользуется менеджерами паролей. Мы используем bitwarden.

Для любого digital-проекта важно хранить доступы:

• к внешним сервисам (почты, домены, аккаунты в сторах, хостинг);

• к серверам (с описанием, какие сервисы запущены на какой машине).

4. Тестовые данные

Если проект состоит из одной посадочной страницы, все рекомендации по тестовому наполнению ограничиваются использованием релевантных текстов и картинок (а не Lorem Ipsum). Но когда речь идет о веб-сервисе, на что обратить внимание:

• большинство современных веб-фреймворков имеют функцию наполнения БД (seeding), необязательно заполнять вручную данные, их можно сгенерировать;

• сгенерируйте огромное количество данных и узнайте, когда сервис перестанет справляться с нагрузкой, как будет открываться список пользователей если их 2 млн. в базе, когда нужно добавлять индексы на таблицы, пересматривать схему БД и. т.д;

• как выглядят интерфейсы при заполненных данных? Правильно ли отрабатывает пагинация, поиск, верстка на месте?

5. 4хх, 5хх, ххх страницы

Никто не застрахован от 500-х ошибок и падения сервера. Но что видит пользователь в этот момент? Debug-log фреймворка или красивую страницу с «мы знаем что-то сломалось, уже чиним» — зависит от разработчика. Наши рекомендации:

• на этапе макетирования позаботиться о дизайне 4хх и 5хх страниц;

• проверить не включен ли debug-мод на продакшене;

• на этапе тестирования сымитировать 4хх и 5хх ошибки и проверить, что будет видеть пользователь;

• на страницу с ошибкой выводить уникальный ID ошибки, с которым пользователь может обратиться в саппорт и ускорить расследование инцидента.

6. Как выглядит интерфейс под разными учетными записями

При демонстрации проекта заказчику, как правило, демонстрируются позитивные сценарии работы сервиса. При составлении чек-листа тестирования проекта следует учитывать как будет выглядеть интерфейс:

• когда в нем не будет ни одной записи (напр. пустая корзина, пустой список заказов);

• при частичном заполнении (напр. указаны фамилия, имя, но нет отчества);

• после валидации полей (в правильных ли местах всплывают подсказки).

7. Стресс-тест

Сделали digital-продукт, запустили трафик, проект упал. Было такое? У нас тоже. Как можно было это предусмотреть заранее: провести стресс-тест. Для несложных проектов можно использовать JMeter, для более сложных — поискать облачные решения, например, loader.io.

И вот уже вы знаете, что 500 одновременных подключений сервис выдерживает, 5000 — нет.

8. Ваш проект запустят на калькуляторе, вы готовы?

В эпоху смартфонов с большой диагональю экрана, все еще остаются пользователи со смартфонами более скромных габаритов.

Необязательно покупать для тестов парк смартфонов, но запустить эмуляцию смартфона и открыть в браузере сервис или мобильное приложение — вполне. Мы так обнаружили, что в приложении на iphone 5s форму регистрации видно, а вот кнопку «Зарегистрироваться» — нет.

Понять оснащенность аудитории помогут логи веб-сервера, в которых, как правило, указывается ОС клиента (по ней можно предположить модель устройства).

9. Откатываемся

Билд готов, протестирован, выкатили на продакшен, посыпались 500-е ошибки. Shit happens. О том, что делать в такой ситуации, можно задуматься заранее и предпринять меры:

• поддерживать stage-среду в актуальном состоянии;

• сине-зеленый деплой;

• согласовать релизы на время минимальной нагрузки.

10. Логируемся

С чего начинается разбор полетов? Конечно, с просмотра логов. Слишком подробные логи — плохо, забивается место на диске; логи вида «500 internal server error(точка)» — заставляют грустить разработчика. Наши советы по этому вопросу:

• настроить ротацию логов (логи старше 1 месяца отгружаются на архивный сервер или удаляются);

• добавить в логи ID для каждой ошибки, это упростит общение по всем линиям технической поддержки;

• не выводить в явном виде пароли пользователей в логах;

• использовать инструменты менеджмента логов (ELK-стек, Sentry);

• не только логировать бэкенд, но и события на фронте (мы используем Sentry)

11. Дашборды со старта проекта

С самого первого дня digital-продукт генерирует данные, которые хранятся в базах данных. Мы взяли за правило: если есть база данных, она обязательно должна показывать свои данные на дашборд.

В стартовый набор метрик входит:

• количество пользователей;

• динамика регистраций;

• динамика business value actions (кол-во заказов, кол-во транзакции).

Заказчик получает приятный бонус в виде пульс-панели проекта, мы видим прогресс на проекте.

Для преобразований данных используем Airflow. Для построения дашбордов используем Metabase (благо поднимается одной строчкой кода в Docker).

Пишите в комментариях, какие уроки вы нашли полезными, а что я пропустил?