Web-технологии

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

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

Я знаю многое о велосипедах в Enterprise-разработке. Видел издали, катался на них, собирал сам, но наступают моменты, когда типичные задачи пора перевести на типичные решения. В статье расскажу о 4 self-hosted сервисах, которые освобождают уйму времени на действительно важные вещи.

Мы в "Искусство Автоматизации" занимаемся заказной разработкой MVP (мобильных приложений, веб-сервисов, чат-ботов) со средним сроком цикла разработки 2 месяца. Это срок, в который нужно уже запустить готовое решение для новых пользователей. Об общих подходах к стабильной разработке ИТ-продуктов рассказал в другой статье, а в этой статье расскажу про инструменты.

За 4 года ведения ИТ-продакшена ярко выделись следующие однотипные запросы к проекту:

• показывать метрики, что происходит с проектом;

• мониторить доступность сервисов;

• шарить статичные файлы (отчеты, сборки);

• интегрироваться с соседними сервисами.

Итак, переходим к самим сервисам.

Metabase

Данные интересны всем. Почти все сервисы сохраняют / агрегируют сведения о нас. Наши проекты тоже не исключение. Типичные запросы на старте разработки: сколько пользователей сейчас в проекте (новых / активных), сколько сделано заказов, какие ресурсы проекта самые посещаемые etc.

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

Вот уже два года в каждом нашем проекте мы используем BI-утилиту Metabase.

Вкратце о возможностях продукта:

• подключение к почти любым источникам данных (SQL/noSQL);

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

• шеринг дашбордов и показателей по ссылке, встраиваемые фреймы.

Килл-фича, о которой мало кто говорит. Metabase можно использовать как API для доступа к вашей БД. Больше не нужно писать контроллеры, поднимаем Metabase, открываем консоль хрома, копируем запросы к бэкенду и используем их в своих проектах. И это все, не написав ни строчки кода.

За 3 минуты можно собрать пульс-дашборд и показать его заказчику

Из минусов Metabase:

• довольно прожорлив к серверным мощностям (Java все-таки);

• скудноватая коллекция готовых виджетов

Сайт проекта | Docker-образ

Uptime Kuma

Про мониторинг проекта можно и не рассказывать. Важно знать о падении сервисов до того момента, пока об этом сообщит заказчик или конечный клиент. На рынке много инструментов, которые закрывают эту потребность. Мы долгое время пользовали Zabbix, но для нас он оказался тяжеловесным. Сейчас используем Uptime Kuma для:

• мониторинга доступности сервисов;

• срока действия SSL-сертификатов;

• получаем уведомления в Telegram.

Не скрою, интерфейс нас тоже подкупил, выглядит по мне более приятно, чем Zabbix

Из минусов, не хватает мониторинга параметров сервера (место на диске, нагрузка). Одной из частых причин недоступности проекта может быть банально закончившееся место на диске. Надеемся, в Uptime Kuma добавится агент, который можно будет поставить на сервер.

Сайт проекта | Docker-образ

NextCloud

В эпоху облачных хранилищ вопрос обмена файлами вроде бы решился. Но по тем или иным причинам не всем подходит размещение файлов на сторонних серверах. Причиной тому могут быть и требования по конфиденциальности данных и тарифная политика облачных сервисов. Мы на своих проектах, если нужно организовать доступ к файлам используем продукт NextCloud. Сервис запускается на сервер и вот у вас есть свой персональный Dropbox.

Интерфейс приятный, чуть-чуть не дотягивает до современных трендов в дизайне, но все равно лучше, чем перетаскивать файлики по FTP

Из плюсов:

• шеринг файлов по ссылке;

• гибкая настройка прав доступа;

• приятный интерфейс.

Из минусов, обнаружили, что при большом количестве файлов в директории (больше 1000), интерфейс подлагивает. Видимо, не завезли lazy-load для списка объектов.

Сайт проекта | Docker-образ

Apache NiFi

На самом деле, это не сервис, а какая-то вакцина от велосипедизма. Представим ситуацию, нужно получить объект из шины данных, выбрать нужные поля, сохранить объект в БД и отправить событие в систему нотификаций по HTTP. Уже руки чешутся написать пару классов на Java и еще пару классов для интеграционных тестов? Не спешите, вопросов много, ответ один - Apache NiFi.

По сути, это ETL-комбайн по построению data-pipelines. Из коробки 100+ коннекторов ко всем популярным источникам данных (шины, базы, HTTP etc). А если вдруг не найдется нужный, можно написать свой.

Настройка data-pipelines происходит в веб-интерфейсе

С внедрением Apache NiFi, мы значительно сократили количество интеграционного кода, а значит сократили вероятность ошибок.

Продукт хорошо согласуется с набирающим популярность NoCode трендом. Получается такой аналог Zapier, только у вас на сервере под полным контролем.

Сайт проекта | Docker-образ

Резюме

Используя готовые self-hosted сервисы можно серьезно прокачать свой проект и добавить новую функциональность, не написав лишний код, который, конечно, будет требовать в будущем ресурсы на свою поддержку.

А какие сервисы используете вы при создании своих ИТ-продуктов?