Всем привет!
Расскажу немного про наши (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. на картинке изображен фрагмент из одного очень веселого фильма, который называется “Билли Мэдисон”, с Адамом Сэндлером. Для меня он повествует о том, что вокруг нас всегда много очевидных явлений и вещей, но мы можем придать им верные нужные значения.
Комментарии (10)
PastorGL
30.11.2021 23:45+8Похоже на описание карго культа. Вы используете уйму инструментов, но из всего этого замечательного перечисления не вытекает ответа на вопрос «зачем это всё?» По-вашему, «не только для автоматизации». А конкретнее?
Отвечаю (как евангелист со стажем): весь этот сыр-бор прежде всего служит для обеспечения непрерывного развёртывания. Автоматизация тут, действительно, лишь побочный эффект.
Но CD отнюдь не всем, на самом деле, и нужно-то. А если нет нужды в CD, искусственно и бездумно навязываемые в угоду современной моде практики будут вам только мешать. И, судя по тону статьи, вам есть над чем подумать.
golubevartem Автор
01.12.2021 08:53Спасибо за мнение, Вы верно подметили, непрерывное развертывание это один из методов. И он может принести как пользу так и вред. Все зависит о потребностей продукта и ряда других факторов.
ZhilyaevDmitriy
01.12.2021 01:07Я так и не понял, что хотел сказать автор. Зачем мне перечисление стека?
Расскажите лучше реальный кейс преодоления боли. Думаю хабр такое больше оценит.
nerudo
01.12.2021 08:28Слушайте, а откуда они вообще взялись? Я помню были сисадмины, потом я вышел покурить (руки набрали похурить), возвращаюсь — хоба, все девопсами заделались
golubevartem Автор
01.12.2021 09:47Что ж, придется дать пояснительную записку)) Данная статья не имела цель пояснить, что такое DevOps и почему это не Автоматизация. Основная мысль статьи в том, что DevOps не решит всех ваших проблем. Даже имея довольно мощный технологический стек, сам стек не сделает за вас работу. Один раз все магически(автоматизированно) настроив, все не заработает само собой. Та же коммуникация, многочисленные сборки, в виду того, что код постоянно пишется, нужно адаптировать-менять конфигурации. Рабочий процесс рядового DevOps может значительно вырасти(в количественном и качественном), по сравнению с тем же инженером эксплуатации. Но DevOps может принести существенную оптимизацию процессов. Убрать узкие места в инфраструктуре, сделать ее стабильной и отказоустойчивой. Улучшить качество выпускаемых продуктов.
caballero
Девопс это вообще непонятно что.