DevOps Engineer
Automotive parts - B2B Retail business
Добавлено
03 мая 2023 в 16:42
Работал на проекте связанного с B2B продажами автозапчастей.
Вводные:
0. Инфраструктура bare-metal в трёх регионах (есть основной 70% прибыли и два региона с 20% и 10%). Регионы никак не связаны между собой. Релиз происходит сначала на два региона с меньшим для бизнеса приоритетом, а на следующей день наблюдаем и принимаем решение о дальнейшей судьбе релиза.
1. Сам B2B (монолит ASP.NET MVC/WCF/Web Api + Angular + MS SQL + Redis + Solr + ElasticSearch), но проект двигался в сторону микросервисов и более современных фреймворков (.net core 3.1/.net 6).
2. CRM и ERP системы для получения связанной информации, используя SQL Job по расписанию для получения данных в B2B базы данных.
3. Мониторинг (Zabbix) и логирование (ELK)
4. Код и текущие pipeline были в Azure DevOps Server.
Проект был стабилен в работе, но потреблял море ресурсов для обеспечения production нагрузки + было много слабых мест в виду отсутствия RnD практик в компании.
Моя работа на проекте:
1. Автоматизация рутины. Каждый Windows Server настраивался в ручную и на это тратилось много времени - написал для начала скрипт который позволял установить всё необходимое ПО и все роли Window Server, а так же скачивал последний артефакт сборки кода и настраивал IIS.
2. Занялся мониторингом SQL job, отвещающих за синхронизацию данных (они отваливались и хотелось бы получать уведомление оперативно).
3. Принято решение о внедрении Kafka для синхронизации данных между внутренними системами и избавления от SQL job. Взял готовый runbook для развертывания Kafka кластера (на тот момент решили двигать в сторону Raft кластера без Zookeeper) + было написано несколько скриптов по настройке Kafka/Debezium Connect для захвата данных с таблиц базы SQL Server + был написан сервис за запись данных из Kafka в SQL Server B2B. Были проблемы с производительностью на текущем железе и отложили ввод в production до закупки нового железа. После введение в эксплуатацию избавились от множества проблем с рассинхронизацией данных между порталом и внутренними системами, также получили платформу для потоковой обработки и трансформации данных.
4. Занялся переписыванием pipeline с Release в Pipeline, для повышения читаемости и быстроты дальнейшей модификации.
5. Внедрении двух кластеров ELK (dev&stagging и production) и перепись всех конвейров доставки и обработки логов.
6. После получения опыта принято решение отказа от Solr (хостился на каждом window server рядом с MVC) в пользу ELK и для этого был развернут отдельный кластер для поисковых активностей.
7. Стандартизирован pipeline для сборки docker image для нескольких микросервисов и deploy на различные environments.
8. Было принято решение о миграции Web Api (написан для интеграции заказчиками нашей системы в их собственные бизнес процессы) на .net 6 и разделении его на два сервиса (web api сервис + auth сервис). Описал и развернул всю инфраструктуру + составил задачу для программистов для ухода от прямой аутентификации в AD для сбора учетных данных в сторону использования LDAP.
9. RnD - ASP.NET MVC in Windows container. С учётом полученного ранее опыта попросил программистов переписать аутентификацию на LDAP и попробовать запуск монолита в Windows Container. Удалось быстро деплоить новый артефакт, по сравнению с артефактами в zip архивах (первый запуск pipeline был длительным из-за большого размера image windows server core). Оптимальная производительность получалась только на bare metal сервере. В случае VM были большие просадки по производительности. Опыт был оформлен в вики и отложен до получения апрува от бизнеса.
Вводные:
0. Инфраструктура bare-metal в трёх регионах (есть основной 70% прибыли и два региона с 20% и 10%). Регионы никак не связаны между собой. Релиз происходит сначала на два региона с меньшим для бизнеса приоритетом, а на следующей день наблюдаем и принимаем решение о дальнейшей судьбе релиза.
1. Сам B2B (монолит ASP.NET MVC/WCF/Web Api + Angular + MS SQL + Redis + Solr + ElasticSearch), но проект двигался в сторону микросервисов и более современных фреймворков (.net core 3.1/.net 6).
2. CRM и ERP системы для получения связанной информации, используя SQL Job по расписанию для получения данных в B2B базы данных.
3. Мониторинг (Zabbix) и логирование (ELK)
4. Код и текущие pipeline были в Azure DevOps Server.
Проект был стабилен в работе, но потреблял море ресурсов для обеспечения production нагрузки + было много слабых мест в виду отсутствия RnD практик в компании.
Моя работа на проекте:
1. Автоматизация рутины. Каждый Windows Server настраивался в ручную и на это тратилось много времени - написал для начала скрипт который позволял установить всё необходимое ПО и все роли Window Server, а так же скачивал последний артефакт сборки кода и настраивал IIS.
2. Занялся мониторингом SQL job, отвещающих за синхронизацию данных (они отваливались и хотелось бы получать уведомление оперативно).
3. Принято решение о внедрении Kafka для синхронизации данных между внутренними системами и избавления от SQL job. Взял готовый runbook для развертывания Kafka кластера (на тот момент решили двигать в сторону Raft кластера без Zookeeper) + было написано несколько скриптов по настройке Kafka/Debezium Connect для захвата данных с таблиц базы SQL Server + был написан сервис за запись данных из Kafka в SQL Server B2B. Были проблемы с производительностью на текущем железе и отложили ввод в production до закупки нового железа. После введение в эксплуатацию избавились от множества проблем с рассинхронизацией данных между порталом и внутренними системами, также получили платформу для потоковой обработки и трансформации данных.
4. Занялся переписыванием pipeline с Release в Pipeline, для повышения читаемости и быстроты дальнейшей модификации.
5. Внедрении двух кластеров ELK (dev&stagging и production) и перепись всех конвейров доставки и обработки логов.
6. После получения опыта принято решение отказа от Solr (хостился на каждом window server рядом с MVC) в пользу ELK и для этого был развернут отдельный кластер для поисковых активностей.
7. Стандартизирован pipeline для сборки docker image для нескольких микросервисов и deploy на различные environments.
8. Было принято решение о миграции Web Api (написан для интеграции заказчиками нашей системы в их собственные бизнес процессы) на .net 6 и разделении его на два сервиса (web api сервис + auth сервис). Описал и развернул всю инфраструктуру + составил задачу для программистов для ухода от прямой аутентификации в AD для сбора учетных данных в сторону использования LDAP.
9. RnD - ASP.NET MVC in Windows container. С учётом полученного ранее опыта попросил программистов переписать аутентификацию на LDAP и попробовать запуск монолита в Windows Container. Удалось быстро деплоить новый артефакт, по сравнению с артефактами в zip архивах (первый запуск pipeline был длительным из-за большого размера image windows server core). Оптимальная производительность получалась только на bare metal сервере. В случае VM были большие просадки по производительности. Опыт был оформлен в вики и отложен до получения апрува от бизнеса.
