Разработчики с Венеры, операторы с Марса
Ребята, ваша девочка получила высшее образование. Я был зациклен на производственном сбое, и у меня была первая драка с командой эксплуатации моего приложения.
Если смотреть объективно, все было не так уж и плохо. Повышенные эмоции и стресс ситуации были более ответственны за поднятые голоса, чем сама проблема. Это определенно не входит в пятерку лучших боев, в которых я участвовал. Сделайте выводы о моей жизни из этого.
Но это был мой первый опыт того, почему DevOps важен для технической команды. Мы - две стороны одной медали, пытаясь создать и поддерживать одно и то же приложение. Имея так много общего, команды разработчиков и операторов, имеющие разногласия и споры, должны быть редкостью.
Зачем нам нужен DevOps?
Традиционно команды разработки и эксплуатации работают в разных направлениях. В то время как разработчики сосредоточены на получении новых функций, новых услуг и новых источников дохода, операционная деятельность сосредоточена на поддержании стабильности существующей производственной системы и отсутствия перебоев и простоев. DevOps - это не процесс. Это командная культура, которая способствует лучшему сотрудничеству между Ops и Dev. Это может произойти двумя способами:
- Разработчики создают стабильные и хорошо протестированные функции.
- Операторы разрабатывают системы для большей наглядности приложения и упреждающего подхода к сбоям.
Когда разработчики работают над созданием новых функций, а также обеспечивают надлежащий мониторинг, знания и прозрачность для Ops, чтобы их поддерживать, именно тогда бизнес выигрывает.
Как DevOps улучшает совместную работу во время простоев?
По моему опыту, культура DevOps уходит корнями в сотрудничество и взаимопонимание. Именно тогда, когда разработчики понимают все трудности операций, и наоборот, оба могут поддерживать друг друга, а не работать друг против друга.
В отличие от Agile и Scrum, инструментами и процессами управляет команда и корпоративная культура. Это помогает следующим образом:
Улучшенные развертывания
Благодаря тому, что команды Ops получают информацию о каждом выпуске и его влиянии, они получают возможность лучше поддерживать приложение. Когда новые функции развертываются безопасно, с тестированием, переключением функций, упреждающим мониторингом, встроенным в конструкцию, количество инцидентов, связанных с отключениями, как правило, сокращается.
В такой культуре, как разработчику, совершенно необходимо учитывать неудачи при проектировании. Даже если сценарии сбоя случаются редко, они могут быть неприятными. Обеспечение постепенного восстановления и / или частичных отказов может быть очень полезным для людей, поддерживающих приложение.
Оповещение и мониторинг - это первоклассные граждане
Когда проект системы учитывает отправку предупреждений в случае сбоев и аномалий, операционные группы лучше оснащены для их обработки, не оказывая влияния на бизнес.
Надежное оповещение и упреждающий мониторинг гарантируют, что сбои будут обнаруживаться тогда, когда они происходят, а не когда пользователи сообщают о них. Это может быть так же просто, как отправка оповещения по электронной почте заинтересованным разработчикам и сотрудникам, когда приложение выходит из строя.
Мы все ладим
«Если Ops ходит на обед с Ops, а Dev ходит на обед с Dev, низкий уровень эффективности очевиден».
DevOps способствует частому взаимодействию между участниками Dev и Ops. Я обычно обращаюсь к команде Ops, когда я вношу потенциально критические изменения в приложение, чтобы узнать их мнение о том, что им потребуется для его поддержки. Такое взаимодействие способствует взаимопониманию и смирению между командами.
С годами у меня сложились хорошие отношения с ними. Я знаю об их семьях, я знаю время, когда многие из них внезапно заболели Covid, и численность команды уменьшилась. Я узнаю об их планах на отпуск.
И при этом с ними становится легче работать в стрессовых ситуациях, например, в отключениях. Это не какой-то неизвестный человек, который молча обвиняет меня и мою команду в написании нестабильного кода (хотя иногда такое может казаться). Это тот, с кем я работаю регулярно. Это способствует совместному решению проблем, а не обвинениям, что в конечном итоге приводит к более быстрому решению и меньшему количеству отвлекающих факторов.
Оповещения инфраструктуры
Это заслуживает особого места в списке.
Как разработчик приложения, я иногда чувствую себя бесполезным, когда звоню из-за сбоя, пока команда инфраструктуры пытается решить проблему. Сбой инфракрасной системы, как и проблемы с нехваткой памяти, также вызывает простои. Если их не поймать вовремя, от них может быть трудно быстро избавиться.
В таких случаях очень важны хорошая видимость и оповещение, а также надлежащая гигиена и техническое обслуживание. Вот как DevOps управляет инструментами и процессами в организации.
Что произойдет после отключения электричества?
Когда случается сбой, это скорее кризисная ситуация. Имеет смысл, чтобы это была ситуация, когда все на месте, независимо от того, являетесь ли вы разработчиком, специалистом по контролю качества, менеджером по производству или кем-либо еще.
Но как только это закончится, наступит время анализа первопричин (или RCA). Были допущены ошибки, и разделяются опасения по поводу того, что было упущено и как мы можем действовать быстрее. Это трудный, но необходимый разговор. Как разработчику может быть неприятно, если проблема возникла из-за того, что Ops упустил, и я могу представить, что то же самое верно и по другую сторону уравнения.
Последний шаг - терпимость. Неудачи случаются. Сбои случаются. Мы все побеждаем в способности терпеть человеческие ошибки с обеих сторон и обеспечивать наличие надлежащих систем, чтобы они не повторялись снова.
Последние мысли
Что касается отключения электричества, в котором я участвовал, в целом это была веселая ночная вечеринка. (Если сарказм не очевиден, я хочу, чтобы вы знали, что это действительно сарказм.)
Хотя иногда температура (и голоса) повышались, мы все вышли из этого как более сильная команда, тем более что RCA не указывало на проблему с нашим приложением (уф!).
Урок для меня был двояким. Операторы - это не только мои клиенты, но и бизнес. Если они не могут поддерживать приложение в меру своих возможностей, оно не сможет поддерживать бизнес так, как должно.
Во-вторых, всегда существуют неизвестные неизвестные. Они могут вызвать сбои и серьезные простои. Единственное, на что мы можем положиться, - это сотрудничество и доверие между разработчиками и ИТ-операциями, которые помогут нам быстрее принимать решения. Как пишет соавтор «Руководства по DevOps» Джез Хамбл:
«DevOps - это не цель, а бесконечный процесс постоянного улучшения».
Подпишитесь на мою личную рассылку, чтобы узнать больше о технологиях, производительности и жизни.
