MariaNovikov171
New member
Когда я пришёл в свою первую компанию в 2018 году, деплой занимал два дня. Инженеры-разработчики писали код, отправляли его на устаревший сервер сборки и молились, чтобы всё заработало в тестовой среде. Я тогда подумал, что так не должно быть. Через полгода мы перешли на автоматизированные пайплайны, и я впервые увидел, как команда начинает дышать свободно. Но настоящий DevOps — это не только инструменты. Это смена мышления, и это оказалось сложнее всего.
Нажать чтобы Перейти на сайт
Мой личный опыт работы в команде из двенадцати человек показал: главным барьером всегда были люди, а не технологии. Разработка считала, что运维 — это чужая проблема, а运维 считал, что разработчики пишут нерабочий код. Мы начали еженедельные встречи, где инженеры обеих сторон обсуждали инциденты. Через месяц напряжение снизилось, через три месяца люди стали свободно обращаться друг к другу с вопросами. Культура меняется не приказами, а диалогом.
Особенно запомнился случай, когда наш сервис упал в пятницу вечером, и вместо поиска виноватых мы вместе сели, восстановили логи, нашли корневую причину и за два часа развернули фикс. Я понял, что blameless postmortem — это не модная фраза из статей, а реальный механизм, который экономит месяцы нервных срывов и увольнений.
Конечно, внедрение DevOps требует инвестиций. Мы тратили время на обучение, покупали инфраструктуру, перестраивали процессы. В первые два месяца метрики ухудшились, потому что команда училась. Руководство почти остановило проект, но я показал данные: за следующие четыре месяца количество инцидентов упало на семьдесят процентов, а время до релиза сократилось в три раза. После этого ни у кого не осталось сомнений.
Узнать подробнее →
Сегодня я работаю в компании, где DevOps — часть ДНК с первого дня. Разработчики сами пишут Docker-контейнеры, сами настраивают мониторинг, сами разворачивают свой код. Я больше не вижу жёсткой границы между командами. Я верю, что DevOps — это не про CI/CD-пайплайны и Kubernetes. Это про доверие, прозрачность и общую ответственность за результат.
А как вы оцениваете культуру DevOps в своей компании? Есть ли у вас практика blameless postmortem, или вы всё ещё ищете виноватых после каждого инцидента? Поделитесь своим опытом в комментариях.
По теме советую почитать: Как я запустил SaaS-продукт за шесть недель
Нажать чтобы Перейти на сайтМой личный опыт работы в команде из двенадцати человек показал: главным барьером всегда были люди, а не технологии. Разработка считала, что运维 — это чужая проблема, а运维 считал, что разработчики пишут нерабочий код. Мы начали еженедельные встречи, где инженеры обеих сторон обсуждали инциденты. Через месяц напряжение снизилось, через три месяца люди стали свободно обращаться друг к другу с вопросами. Культура меняется не приказами, а диалогом.
Особенно запомнился случай, когда наш сервис упал в пятницу вечером, и вместо поиска виноватых мы вместе сели, восстановили логи, нашли корневую причину и за два часа развернули фикс. Я понял, что blameless postmortem — это не модная фраза из статей, а реальный механизм, который экономит месяцы нервных срывов и увольнений.
Конечно, внедрение DevOps требует инвестиций. Мы тратили время на обучение, покупали инфраструктуру, перестраивали процессы. В первые два месяца метрики ухудшились, потому что команда училась. Руководство почти остановило проект, но я показал данные: за следующие четыре месяца количество инцидентов упало на семьдесят процентов, а время до релиза сократилось в три раза. После этого ни у кого не осталось сомнений.
Узнать подробнее →Сегодня я работаю в компании, где DevOps — часть ДНК с первого дня. Разработчики сами пишут Docker-контейнеры, сами настраивают мониторинг, сами разворачивают свой код. Я больше не вижу жёсткой границы между командами. Я верю, что DevOps — это не про CI/CD-пайплайны и Kubernetes. Это про доверие, прозрачность и общую ответственность за результат.
А как вы оцениваете культуру DevOps в своей компании? Есть ли у вас практика blameless postmortem, или вы всё ещё ищете виноватых после каждого инцидента? Поделитесь своим опытом в комментариях.
По теме советую почитать: Как я запустил SaaS-продукт за шесть недель