Всем привет!
Расскажу немного про наши (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. на картинке изображен фрагмент из одного очень веселого фильма, который называется “Билли Мэдисон”, с Адамом Сэндлером. Для меня он повествует о том, что вокруг нас всегда много очевидных явлений и вещей, но мы можем придать им верные нужные значения.