Войти через соцсеть:
Войти через email:
Ученье — свет, а обучение — фонарь, солнце или сверхновая. Но как сделать из искры источник вечного света в ИТ?
Важно понять, что все мы можем быть учителями в той или иной области, но кто и как получает пользу от обучения?
Обсудим столпы 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.