Кто всё ломает (change factor)
Откуда грабли появляются при нормальном, правильном процессе? Они будут, их не может не быть. Вы их туда приносите сами; это — сюрприз — правильно и важно.
Поводом послужил диалог внутри нашей очередной сходки «крутильщиков планеты», как шутим. Внутри узких отраслей народу обычно не так много, и все топовые специалисты друг друга знают. И общаются за калычем, за чилийским и просто под настроение. Это мы.
И вот ситуация, смотрите. У нас есть контора (федерального масштаба). В ней выстроены разработка, проектирование, приемка-QA, внедрение, эксплуатация — везде всё относительно хорошо и по плану. Но периодически на эксплуатации что-то падает, наворачивается, и идет через задницу.
Логичный вопрос руководства, как и эксплуатационщиков: ну какого хрена так происходит? Мы же ниибаца солидная контора.
У нас работают сотни, иногда тысячи людей, пздатых специалистов, мы херовых не брали. У нас есть камазы бюджетов, чтобы сделать как надо. Откуда звиздецы-то?
На наших продуктах 24×7 живёт миллионная страна, очень не хочется опять в соцсетях читать «ABC налажали», и бабло терять миллионами.
Важный момент диагностируется сразу: речь не идет о «внешних воздействиях», с ними понятно. Наша инфра держит Х3 запаса по нагрузкам, даже под новый год. Нас невозможно пойти и сломать рядовыми мамкиными хацкерами, как и залить DDOS-ом наглухо (наливалка такая не выросла). Мы держим даже собственные фейловер-цепочки — штатно и не чихая, пусть и неудобно, тоже с запасом прочности примерно Х3.
Ответ простой: мы сами всё ломаем.
Разработка и проектирование плодят нестабильности, challenges и сложные ситуации именно своей работой: они всё меняют. По конкретным причинам: рост, развитие, изменение сервисов, контуров, новые продукты, новые решения.
Эксплуатация и внедрение своей работой занимается именно тем, чтобы вот эти источники нестабильностей — по факту! — сделать штатными, предсказуемыми, управляемыми и так далее.
Одни ломают, вторые стараются удержать. Это не «пц там девы пидоры всё сломали». Это плата за развитие и за амбиции, это нормально, без этого не получится. Это штатный процесс, и это можно наглядно показать.
И важно, чтобы все, включая руководство, это понимали.
Если отладка — это нахождение ошибок, следовательно программирование — процесс их внесения. Но речь не только про айти.
Есть логичный и предсказуемый способ сделать так, чтобы ничего не менялось. Залить всю систему эпоксидной смолой, следом закатать в бетонный бункер, и тогда ничего там не поменяется никогда. Переживёт поколения.
Если инженерное решение и его реализация на 100% соответствует задачам — а что, хороший путь. Кроме шуток, физические инженерные системы так и ограждают от реального мира: буквально, заливают эпоксидкой и помещают в независимый контур. Будет работать неизменно, предсказуемо, до полной наработки на отказ. Работает — не трогай.
Логическая проблема в чем: а нам надо трогать.
Надо реализовывать новые возможности. Надо добавлять фичи. Надо менять составляющие, ускорять, оптимизировать. Иначе в условиях эксплуатации наш брутальный кусок эпоксидки станет всё еще надежным и работающим, но уже не отвечающим современному запросу к его возможностям. Следовательно, бесполезным.
Надо как-то реагировать на окружающий мир, теми же способами. Надо реагировать на изменения внешних систем, чтобы наша внутренняя продолжала нормально с ними работать.
Надо менять функциональность так, чтобы соответствовать изменяющемуся миру. Надо поддерживать количественные изменения нагрузок и объемов: как правило, невозможно увеличить нагрузки (технические, административные) на порядки, и остаться в том же решении. Невозможно обеспечить скейл свыше изначально запланированных аппетитов, чтобы ничего не треснуло губа, например. Если этого всего не делать — снова приходим к неизменному, но уже бесполезному куску решения.
Вот здесь изменения. Вот здесь нестабильности.
Вот здесь риски и сложные случаи.
Ничего не трогаем, никаких фичей, никаких правок, никаких сторонних вмешательств — и будет работать как часы веками.
Влезть на эту ёлку роста и развития в заданном темпе, и совсем не ободрать задницу по пути — скорее всего, не получится.
Получается два «противоборствующих лагеря», и это нормально
- проектирование и разработка реализуют кучу всего перспективного, выигрывают в фичах и возможностях, теряют в стабильности
- приемка, внедрение и эксплуатация работают в противовес, стараются не разломать существующее и обработать риски, но сохранить стабильность
Здесь нет смысла принципиально бодаться, и обкладывать друг друга уями. Это не Вася-проектировщик опять мудак, и не Петя-эксплуатационщик упёртый и тугой. Это базовые правила игры. Пойдите, накатите обнявшись, и согласуйте решение с процессом, которое у вас в пару обоих двух, на выходе, ничего не навернёт.
Знаю много ребят, которые и тех и других принципиально делят административно на два крупных лагеря: проектировщики и эксплуатационщики. В цифровом айти, по массе, это позиционная баталия «dev-ы против ops-ов». Ну, окей, почему бы и нет.
Просто в истерики впадать не надо.
Если ничего не менять, ничего и не поменяется. Цена перемен — нестабильность.
С ней можно и нужно работать, на обоих сторонах.
Как работать — считайте change factor (хотя бы процентовку, в чем угодно). Сколько мы можем позволить себе объема потоковых изменений, по времени, чтобы с одной стороны успеть за меняющимися требованиями, и с другой стороны, не вылететь за рамки ожиданий по рискам и нестабильностям.
Инженерные подходы тоже есть. Самый простой, креативить и шатать в одном месте, выдерживать стабильность в другом (прошлом), по достижению заданных нормативов менять старое на новое. Но это только самый простой.