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

Порой случаются события, которые не должны случаться. Мы в “Искусство Автоматизации” за 4 года создания digital-продуктов собрали все из них (ну или те, что касаются IT продуктов). Делимся опытом, инструментами и подходами, которые сделали нашу деятельность стабильнее.

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

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

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

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

валидности SSL-сертификата;
доступности сервиса (HTTP 200);
телеметрии сервера (свободное место, нагрузка на CPU, загрузка RAM).

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

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

Наши выводы:

бэкапить проект у разных хостинг-провайдеров;
скриптом проверять наличие бэкапов, нет бэкапа -> пуш в Telegram-бота;
исходников в Git недостаточно, бэкапить не только базу, но и код с конфигами;
шифровать бэкапы;
раз в N-месяцев проверять сохранность данных, восстанавливаясь из бэкапов.

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

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

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

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

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

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

на этапе макетирования позаботиться о дизайне 4хх и 5хх страниц;
проверить не включен ли debug-мод на продакшене;
на этапе тестирования сымитировать 4хх и 5хх ошибки и проверить, что будет видеть пользователь?
на страницу с ошибкой выводить уникальный ID ошибки, с которым пользователь может обратиться в саппорт и ускорить расследование инцидента.

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

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

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

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

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

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

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

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

поддерживать stage-среду в актуальном состоянии;
сине-зеленый деплой;
согласовать релизы на время минимальной нагрузки.

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

настроить ротацию логов (логи старше 1 месяца отгружаются на архивный сервер или удаляются);
добавить в логи ID для каждой ошибки, это упростит общение по всем линиям технической поддержки;
не выводить в явном виде пароли пользователей в логах;
использовать инструменты менеджмента логов (ELK-стек, Sentry);
не только логировать бэкенд, но и события на фронте (мы используем Sentry)

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

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