DevOps & Администрирование

Ученье — свет, а обучение — фонарь, солнце или сверхновая. Но как сделать из искры источник вечного света в ИТ?

Важно понять, что все мы можем быть учителями в той или иной области, но кто и как получает пользу от обучения?

Обсудим столпы devops: автоматизация, сотрудничество, коммуникация, близость, масштабирование в разрезе обучения.

- Монорепозитории и мультирепозитории: куда идти и зачем в этом разбираться?

- Renovate, как инструмент управления зависимостями, или как получить еще одного бесплатного* разработчика в команде;

- Что такое централизованное и децентрализованное управление зависимостями?

- Проблемы разделения CI\CD процессов по разным репозиториям, устаревания CI-шаблонов и варианты решения этих проблем;

- Inner Source - панацея или помеха

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

В выступлении я на своём личном опыте председателя ТСЖ расскажу об общности и разности подходов, а также о том, чему может научиться DevOps или SRE в эксплуатации собственных систем из реального мира.

Что делать когда у вас есть разработчики (код), сисадмины (инфраструктура) и тестировщики, но нет тех кто наладит общение между этими тремя лагерями.

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

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

Билайн - большой телеком оператор, который до 2021 года делегировал разработку ПО для своих нужд вендорам.

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

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

- "В опеншифте это из коробки" (© народная мудрость)

- "Ну и где теперь этот ваш опеншифт?" (© Джастас Уолкер - веселый DevOps)

Openshift решает большое количество задач, которые в Kubernetes оставлены на откуп пользователя - разграничение прав, безопасность, процесс деплоя приложений в кластер и т.д. Отдельным пюсом Openshift, особенно для enterprise компаний, является коммерческая поддержка.

Но к сожалению, его использование на территории страны теперь крайне затруднено, и компании вынуждены искать замену.

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

В российских IT-компаниях термин SRE стал модным синонимом эксплуатации.

При этом в оригинале SRE - это конкретные принципы эксплуатации, сформулированные в Google, и они являются естественным продолжением остальных особенностей культуры внутри Google и не факт, что подходят любой другой компании, тем более в России.

Что же было до появления SRE? Те, кто работал в крупных компаниях, могли сталкиваться с ITIL - библиотекой лучших практик.

ITIL имеет намного большую сферу приложения, чем SRE, но следующие части ITIL пересекаются с SRE:

* Управление доступностью

* Управление производительностью

* Контроль за изменениями

* Управление инцидентами

* Мониторинг и реакция на события

* Управление проблемами

* Управление релизами

* Управление конфигурацией

* Управление непрерывностью

* Процессы поддержки

* Менеджмент SLA

* Менеджмент заявок

* Управление валидацией и тестированием

* Управление развёртыванием

* Управление инфраструктурой и платформами

* Управление разработкой

Неплохо, неправда ли? Одних заголовков хватит, чтобы набросать процесс работы команды эксплуатации.

На фоне ITIL SRE превращается в "мы не объясним как вам наладить эксплуатацию, но вы должны быть инженером и писать код". Фундаментальные вещи в SRE: риски, SLO/SLI, мониторинг - это база в ITIL, которую в ITIL уже снабдили подробной инструкцией по внедрению.

Место SRE - в треугольнике с ITIL и DevOps. С одной стороны SRE не предлагает принципиально новых процессов эксплуатации, а с другой предлагает конкретную реализацию принципов CALMS из философии DevOps.