Администрирование на аутсорсе: как это работает. Опыт Eats.World

Приложение не грузится из-за ошибок в настройках кластера, а доступов к этому
кластеру нет — с такой проблемой в Southbridge пришла компания Eats.World. Доступы остались у предыдущего подрядчика, с которым Eats.World расстались. Нам предстояло взломать кластер, вернуть приложение к жизни и навести порядок в служебных сервисах, чтобы проблемы не повторились.

В этой статье описываем процесс работы с заказчиком и показываем, какие технические ошибки совершили предшественники.

Осматриваемся на местности

Eats.World доставляет еду из ресторанов и параллельно помогает бизнесу в HoReCa налаживать цифровизацию и обучать сотрудников. Ключевой продукт компании — мобильное приложение по заказу и доставке еды Eats. Оно то и работало со сбоями из-за проблем в инфраструктуре.

Кластер был развёрнут на виртуальных машинах KVM, а доступа к ним не было. Предыдущий аутсорсер удалил всех ssh-пользователей, создал пользователя user, а пароль от него не сказал и при этом запретил доступ по паролю через ssh.

Не стартовали поды, отсутствовали данные в кластере ElasticSearch, в результате в мобильном приложении отказала часть функционала, работа проекта была нарушена.

Состояние сервисов в кластере на момент начала работ (из переписки):

Стек технологий, который используют в компании клиента: Gitlab, Kubernetes, Helm, Kafka, Hazelcast, Elasticsearch, Cassandra, Ceph, Prometheus, Grafana, Clickhouse, Minio.

Штурмуем кластер и тушим то, что горит

Первым делом мы создали телеграм-чат для оперативной связи с командой Eats.World, запросили имеющиеся доступы и определили список приоритетных задач.

Так как доступов к проблемному кластеру и виртуальным машинам KVM не было, пришлось их буквально взламывать. Наконец прорвав оборону, в консоли увидели такое ~~кладбище процессов~~ приветствие:

Восстанавливать работу приложения мы начали вручную, но быстро поняли, что эффективнее написать скрипты импорта/экспорта данных из Cassandra в Elasticsearch. В процессе восстановления эти действия приходилось выполнять довольно часто.

Приложение начало работать, но прогружались не все точки и встречались дубли:

При содействии клиента я убрал дубли в базе данных. Вместе мы сначала искали дублирующиеся записи в одной таблице, затем в другой смотрели, на какую запись они указывают, и удаляли лишние (из Cassandra и Elasticsearch). Так же делал экспорт записей из Cassandra в Elasticsearch.

DevOps-инженер Southbridge Александр Осипов

В конце концов мы убрали дубли и нашли причину, по которой не прогружались точки: у проблемных точек не в кэше не было значений из Hazelcast. Мы запускали миграции и перезапускали медиахостинги, в итоге все данные подтянулись, приложение заработало как надо.

Наводим порядок

Когда решили срочные задачи, перешли к плановым — менее приоритетным, но не менее важным.

Настроили мониторинг и заметили высокую нагрузку в кластере. Её создавало программное обеспечение, которое написал предыдущий аутсорсер. Это ПО управляло служебными сервисами внутри кластера: устанавливало и настраивало их. Так как ПО закрытое, посмотреть его код и что оно делает мы не могли. Зато могли отключить. Ситуация с нагрузкой в кластере улучшилась.

Графики нагрузки до и после отключения ПО, управляющего службами кластера

Иногда о проблемах мы узнавали сами, иногда от сотрудников Eats.World. Вот пример последнего:

Ниже список основных работ с некоторыми деталями.

❌Когда запустили серверы и кластер Kubernetes, оказалось, что в кластере Elasticsearch нет данных на одном из трёх узлов. В настройках узла Elasticsearch не был убран параметр: "cluster.initial_master_nodes: elastic-0". Узел не мог добавиться в существующий кластер и создавал новый из одного узла.
✔️Опцию убрали, узел успешно присоединился к кластеру.

❌Не запускалась Kafka, так как было исчерпано места на PV в кластере.
✔️Место добавили, Kafka запустилась.

❌Некоторые приложения в окружениях dev и prod использовали один кластер Kafka.
✔️Внесли изменения в helm-чарты для разделения окружений.

❌Плохо работал выпуск ssl-сертификатов. Для приложений клиента не был настроен автоматический выпуск сертификатов для https. Cертификаты хранились в CI проектов. Cert-manager был собран из образа предыдущего аутсорсера.
✔️Заменили образ cert-manager на стандартный, прописали аннотацию для автоматического выпуска ssl-сертификатов.

✔️Возникла задача ручного управления кластерами Hazelcast. Развернули “management-center (веб-интерфейс для ручного управления кластером), интегрировали в кластер.

✔️По просьбе клиента заполнили индекс в Elasticsearch на основании данных из Cassandra. Типы данных и структура индекса приведены к необходимому для приложения виду.

✔️ По просьбе клиента часто приходилось вручную редактировать данные в кластере Cassandra, вносить изменения в схему. Поэтому реализовали ежедневный бэкап кластеров Cassandra на удаленный сервер. Восстановление данных из бэкапа Cassandra уже использовалось при откате на предыдущую версию в dev-окружении.

✔️ Клиент разработал приложение на Flask, которое позволяет обслуживать внутренние данные основного приложения через веб-интерфейс. Для приложения мы написали helm-chart, настроили CI (без утилиты деплоя от предыдущего аутсорсера). Персистентные данные приложения хранятся в ceph rbd.

✔️ Решили вопрос повышенной нагрузки на кластер.

Чем дело кончилось

За несколько месяцев мы вместе с клиентом восстановили доступы, наладили работу приложения, исправили ошибки и устранили проблемные места, переделали мониторинг. Теперь поддерживаем проект 24/7.