Автоматизация в DevOps: как и сколько стоит?

• Вячеслав Федосеев, руководитель команды и наставник курса DevOps Upgrade, приветствует участников вебинара.  

• Вебинар проходит в учебном центре Слем, который предлагает множество курсов.  

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

• Девятый поток курса стартует 30 числа.  

• Курс включает разбор основных технологий и реальных кейсов.  

• Вячеслав представляет гостя вебинара, Андрея, который делится своим опытом и юмором.  

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

• Важность понимания стоимости автоматизации.  

• Андрей делится своими мыслями о выборе профессии DevOps и возможных итогах работы в этой сфере.  

• Конфликт между DevOps и разработчиками существует из-за непонимания их роли.  

• Разработчики часто не осознают важность автоматизации и её влияние на производство.  

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

• Автоматизация часто рассматривается как вложение в маркетинг, а не в реальное сокращение времени.  

• Автоматизация требует постоянного обновления и улучшения, что приводит к увеличению затрат.  

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

• Автоматизация должна работать без вмешательства оператора минимум год-два-три.  

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

• Вопрос рентабельности автоматизации: если конвейер ломается, затраты на его поддержание остаются высокими.  

• Автоматизация необходима, если это не единичная операция.  

• Автоматизация оправдана, если стоимость ручной работы выше стоимости автоматизации.  

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

• Автоматизация не всегда оправдана, особенно если задача выполняется редко.  

• Важно уметь считать затраты на автоматизацию и ручную работу.  

• Автоматизация может привести к ошибкам и проблемам, если не учитывать все аспекты.  

• Инженеры должны уметь считать затраты на автоматизацию и ручную работу.  

• Важно предсказывать, когда автоматизация потребуется переписывать или дорабатывать.  

• Инженеры должны ответственно подходить к своей работе и учитывать долгосрочные перспективы.  

• Джуны должны учиться предсказывать и рассчитывать затраты на автоматизацию.  

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

• Неправильное внедрение технологий может привести к проблемам и недовольству коллег.  

• Хороший джуниор может стать хорошим инженером, если будет думать о будущем.  

• Есть два пути: учиться предсказывать и автоматизировать задачи или расти как обычный специалист.  

• Некоторые команды уже научились различать дешевую и дорогую работу.  

• Дешевая работа, как анси и траформ, требует одного инженера.  

• Дорогая работа, как губернетис, требует сеньора с опытом.  

• Сеньоры могут предсказывать проблемы и предлагать решения.  

• Важно, чтобы автоматизация была понятна другим разработчикам.  

• Три основных закона автоматизации: не пиши огромные шаблоны, не превращайся в инфрастрак через код, не возлюби разработчика.  

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

• Разработчики могут деградировать, если не получают обратной связи.  

• Методологии и удобства для разработчиков могут привести к проблемам.  

• Девопсы должны быть готовы к кризисам и помогать архитекторам.  

• Проблемы автоматизации остаются актуальными.  

• Платформа инженеринг не решает всех проблем.  

• Важно понимать, когда автоматизация не стоит затрат.  

• Шаблонизация может привести к проблемам, если не соблюдать простые принципы.  

• Автотестирование должно быть ограничено юнит-тестами.  

• Разработчики часто усложняют процесс сборки, что приводит к проблемам.  

• Идеальная автоматизация в разработке не существует.  

• Дисциплина в производстве важна, но часто нарушается.  

• Внедрение новых функций может привести к конфликтам и необходимости рефакторинга.  

• Форкание кода и обновление версий становится нормой.  

• Рефакторинг требуется каждые три года из-за изменений в технологиях.  

• В эпоху Open Source обновления становятся сложными и требуют значительных усилий.  

• Обновления Kubernetes требуют значительных ресурсов и времени.  

• Уязвимости в старых версиях могут привести к серьезным проблемам.  

• Субъективный опыт разработчиков часто приводит к ошибкам и проблемам.  

• Обновления Kubernetes требуют планирования и подготовки.  

• Ошибки и проблемы неизбежны при внедрении новых версий.  

• Бизнес и IT часто конфликтуют из-за обновлений, что приводит к задержкам.  

• Стоимость обновлений зависит от масштаба проекта.  

• Маленькие проекты могут работать без обновлений годами.  

• Большие проекты требуют регулярных обновлений из-за уязвимостей и новых функций.  

• Обсуждение выбора профессии в DevOps.  

• Диалог о том, как избежать ошибок и выбрать правильный путь.  

• Завершение с надеждой на то, что никто не передумал идти в DevOps.  

• Базовые образы полезны, но не всегда стоит заморачиваться с их созданием.  

• Проблемы нужно решать по хорошему процессу, а не городить сложные вещи.  

• Пример из практики: проблема с Kubernetes у заказчика, решение найдено через базовые образы.  

• Проблема с базовым образом, который не работает должным образом.  

• Расследование показало, что проблема в конфиге, который был добавлен без учета всех команд.  

• Решение: вернуть базовый контейнер без изменений, проблема решена.  

• Базовые образы могут быть полезны для уменьшения веса, но риски велики.  

• Пример с Volt: инженеры часто добавляют ненужные компоненты в базовые контейнеры.  

• Вопрос: что такое базовый контейнер и нужно ли добавлять в него что-то лишнее?  

• Автоматизация может привести к новым проблемам, которые разрушат бизнес-процессы.  

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

• Если не удается объяснить, можно просто не автоматизировать, но это не значит, что что-то сделано плохо.  

• Менеджмент должен уметь управлять процессами и строить их правильно.  

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

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

• Обсуждение стоимости инфраструктуры и шаблонов.  

• Проблема с переписанием кода и желанием разработчиков использовать шаблоны.  

• Пример с зеленым банком, где 100 мастеров Jenkins и 300 тысяч строк кода.  

• Платформизация как процесс объединения различных инструментов.  

• Проблемы с реализацией замечаний разработчиков без дополнительных инструментов.  

• Опасность превращения платформы в "кровавый энтерпрайз".  

• Важность правильного разграничения CI/CD и тестирования.  

• Проблемы с использованием конфигураций и конфигурационных карт.  

• Пример с Kubernetes и тестированием контейнеров.  

• Идея монорепозиториев и их проблемы.  

• Шаблонизация и её влияние на обновление кода.  

• Возвращение к обсуждению шаблонизации и её последствий.  

• Шаблонизация позволяет использовать один объект для множества проектов.  

• Важно поддерживать форки шаблонов, чтобы они оставались актуальными.  

• Поддержка шаблонов может быть дорогой и требует команды.  

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

• Не стоит делить инструменты по функциям, лучше использовать их по необходимости.  

• В крупных организациях могут позволить себе сложные шаблоны, но это требует больших ресурсов.  

• ИИ может помочь в поддержке больших систем, но не заменит DevOps.  

• ИИ может автоматизировать задачи, но не заменит человеческий интеллект.  

• В будущем ИИ будет использоваться для поддержания больших систем.  

• Курс стартует в понедельник и охватывает основные технологии DevOps.  

• Подходит как для новичков, так и для опытных инженеров.  

• Включает пять основных технологий и помогает найти работу в DevOps.  

• Курс предлагает групповые занятия, карьерные консультации и индивидуальную поддержку.  

• Цены варьируются, но можно получить скидки.  

• Курс включает базовую терраформ базу и советы от токсичного техдира.  

• Вопрос о поддержке сайта: поддерживать нужно только свои собственные проекты.  

• Если сайт не работает, значит, есть проблемы с его созданием.  

• Джуны могут экспериментировать и пробовать новые подходы без тим лида.  

• Тим лид может быть недоволен, но это нормально.  

• Важно не бояться экспериментировать и учиться на ошибках.  

• Быстрое написание кода не всегда приводит к плохому результату.  

• Код должен выполнять свою задачу, а не быть идеальным.  

• Эксперты могут критиковать код, но важно, чтобы он работал.  

• Платформы требуют стандартизации и бюрократии.  

• Это может привести к задержкам и неэффективности.  

• Платформы подходят для крупных компаний, готовых к изменениям и бюрократии.  

• Монорепы подходят для маленьких команд, но не для больших.  

• В больших командах монорепы могут быть сложными и дорогими в поддержке.  

• Разработчики могут использовать монорепы, но это требует тщательного планирования и поддержки.  

• Автор не любит большие шаблонизированные системы, так как они дорого обходятся.  

• Пример с аутсорсинговой командой, которая создала большой шаблон в Gitlab, что привело к множеству ошибок и затрат.  

• Предпочитает микросервисную автоматизацию с минимальным количеством шаблонов.  

• Важно упрощать требования и автоматизацию, чтобы избежать кризисов.  

• Автоматизация должна быть концептуально продумана и оптимизирована.  

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

• Автоматизация должна быть простой и оптимизированной.  

• Пример с заводами, где простые операции приводят к высокой производительности.  

• Важно понимать, что каждая версия продукта – это просто новая версия болванки.  

• Пример переезда Kubernetes с 100 миллионами устройств и пиковой нагрузкой 600 тысяч RPS.  

• Грамотное планирование и понимание процессов автоматизации важны для успешного переезда.  

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

• Компания стремилась к безопасности и надежности.  

• Разработчики хотели реализовать определенную фишку.  

• Kubernetes был использован как запускатор контейнеров без секретов.  

• Kubernetes стал ненужным для многих функций.  

• Меньше усилий требуется для поддержки Kubernetes.  

• Люди начали создавать новые Kubernetes, что привело к множеству стандартов и платформ.  

• Люди начали создавать новые Kubernetes из-за проблем с существующими.  

• Появились такие платформы, как K8s, Docker, и другие.  

• Проблема в том, что задачи решаются неправильно, и новые платформы не всегда решают проблемы.  

• Существует множество Kubernetes, стандартов и платформ.  

• Новые платформы не всегда решают проблемы, а только создают новые.  

• Вебинар завершается, и участники приглашаются на будущие встречи.