Как стать автором
Обновить
0
«Кросс технолоджис»
Системный интегратор и разработчик ПО

DevOps — это не автоматизация

Время на прочтение4 мин
Количество просмотров7.5K

Всем привет!

Расскажу немного про наши (DevOps) процессы в компании.

Техничка

Наш DevOps отдел поддерживает все технологические процессы Отдела разработки.
Также выполняем запросы от остальных департаментов компании.

Системой контроля версий является Gitlab. В нем же собираются сборки.
Разработчики используют .NET стек и пишут на C, C#.

Nuget хранилище и Docker Registry также находятся в Gitlab.

Почти все бинарники как для Linux окружений так и для Windows собираются в Kubernetes.

Кластеры строятся на минимальных конфигурациях: 3 мастера + n..workers.
Разворачиваются с помощью Ansible плейбуков по требованию.

Вся инфраструктура лежит в Git. Используется подход Iac.
Всё, от конфигурирования DNS серверов до установки обновлений на Linux хосты, всё управляется через CI.

Инфраструктура состоит как из Linux окружений так и Windows.
Всё мониторится посредством Prometheus, Node Exporter, Grafana + доп экспортеры.

Для связи с разработчиками используется Mattermost.
Для видеоконференций - BigBlueButton.

Многие компании используют тот же Slack (мы раньше тоже его использовали) и этого им вполне хватает.

Мы же перешли на self-hosted решения по причине нестабильности работы слака (как и многих других online-сервисов) еще в 19 году, во время начала пандемии.

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

Но даже после того как нагрузки стабилизировались, мы всё равно остались на self-hosted решениях.

Работают всё же они стабильнее, плюс вся переписка и переговоры ведутся внутри компании.

Также, Mattermost используется для автоматического сбора метрик и алертов от инфраструктуры, сборок и пр.

Туда же автоматом падают ссылки на релизы для бизнеса, во время выпуска.

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

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

Тестовая инфраструктура расположена на мощностях VMware Vsphere в купе с Terraform (ноды и дисковые пулы мониторятся теми же Prometheus, Grafana).

Это много упрощает развертывание стендов, так как все они разворачиваются из Gitlab.
За минуты разворачивается необходимое окружение и туда же с помощью того же Gitlab можно накатить тестируемый продукт, без необходимости ручной установки.

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

На всех сборках настроены автотесты. Написанные как разработчиками, так и командами тестировщиков и DevOps.

Пишите как можно больше тестов!

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

В ранее упомянутый Mattermost падают алерты о сломанных сборках, и DevOps инженер уже в курсе где, что сломалось. В итоге проблема чаще всего устраняется еще до того, как пользователь захочет завести задачу в Jira или написать о проблеме в мессенджер.

Для хранения секретов и паролей используется Hashicorp Vault.
Основное применение у нас, в CI сборках, позволяет не хранить секреты и пароли в репозиториях.

Практики

Взаимодействие между командами является одним из главнейших механизмов направления DevOps в нашей компании.

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

Как раз это взаимодействие и поддерживается с помощью Mattermost и BigBlueButton. Это еще один плюс в копилку self-hosted инструментов.

Так как на них не влияют внешние факторы, можно полностью сосредоточиться на рабочем процессе.

Еще хочется отметить, что при построении инфраструктуры и ее компонентов, не стоит сильно ее усложнять. Там где это возможно, необходимо настраивать простые и надежные сервисы. Не писать огромные скрипто-комбайны, чтобы не тратить потом свое время и время коллег на поиск причины аварии. А если таковые всё же существуют, особенно legacy, постарайтесь уйти от этих инструментов, переписать, заменить. Проще говоря улучшить технологический процесс.

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

Заключение

В заключение хотелось бы сказать.

Автоматизировать можно всё, но не всё можно нужно автоматизировать.
Хотя мое мнение не стоит на том, что DevOps это только автоматизация.

Использование всех практик и методологий DevOps, в купе с хорошо налаженной коммуникацией внутри компании, принесут довольно быстро желаемый результат.

Если вам близка тема, пожалуйста, поделитесь своим опытом в комментариях. Спасибо за проявленное внимание.

P.S. на картинке изображен фрагмент из одного очень веселого фильма, который называется “Билли Мэдисон”, с Адамом Сэндлером. Для меня он повествует о том, что вокруг нас всегда много очевидных явлений и вещей, но мы можем придать им верные нужные значения.

Теги:
Хабы:
Всего голосов 16: ↑5 и ↓11-6
Комментарии10

Публикации

Информация

Сайт
crosstech.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия

Истории