Немного пятничных размышлений на тему сложных взаимоотношений между разработкой, тестерами, эксплуатацией и информационной безопасностью.
Предположим, есть сферическая семья в вакууме, в которой исторически сложилось, что вся посуда, которая пачкается в течении дня, складывается где-то на кухне и дожидается возвращения мужа с работы для героической загрузки в посудомойку. При этом ему сначала приходится отмачивать посуду (засохшую утреннюю кашу ни одна посудомойка не возьмет) и только потом уже загружать в посудомойку. На эту работу у мужа уходит до 30 минут вечернего времени (больше 7 суток в год!). А ведь можно было сразу после трапезы слегка ополоснуть посуду и сразу в посудомойку поставить, затраты усилий и времени при этом минимальные. Получается, что в силу особенностей человеческого восприятия от других членов семьи скрыта добавленная трудоемкость возникающая вследствие их бездействия, ведь они самостоятельно не сталкивается с вынужденным замачиванием посуды и оттиранием прилипшей каши.
К чему это я? А я про специализацию и строгое разделение труда. Узкая специализация, которая считалась благом, оказывается добавляет трудоемкость в совершенно неожиданных местах, причем участники процесса этого не замечают.
Если Dev и Ops живут раздельно, получается, разрабу совсем не нужно думать о развёртывании приложения и откатом, если это необходимо… Как Ops может обеспечить откат падающего релиза если понятия не имеет как все внутри устроено (например, какие миграции в данных произошли) и разработка ему никаких инструментов не предоставила? Сопровождение скорее всего напоминает ад в этом случае и не удивительно, что появляется бюрократия с передачей документации.
Если Dev и QA живут изолированно друг от друга, то у разработчиков возникает соблазн запилить фичу абы как, ведь есть QA, они проверят. При этом разрабатываемое ПО сложно проверять на качество, потому что оно разработано без учета потребностей QA (хотя, как правило, это почти ничего не стоит). На проверку граничных условий времени не хватает, а выкатывать релизы становится страшно.
Взаимодействие Dev и Sec вообще отдельная история, которая часто демонстрирует синдромом вахтера в крайних проявлениях. Если это так, то удобство разрабатываемого ПО для конечных пользователей будет ужасным.
Знакомая ситуация?
Будучи Dev, только беря на себя часть ответственности и задач QA, Ops и Sec можно избежать добавления скрытой трудоемкости и добиться того, что разрабатываемое ПО будет легко модифицироваться, качество будет встроенным, поддержка простой и с нужным (достаточным) уровнем безопасности. Именно это и есть DevOps (DevSecOps, DevSecQAOps), культура сотрудничества и единства целей. Ops не отвечают за стабильность, за стабильность отвечает ВСЯ команда и Dev и QA и Sec. При этом Ops отвечает и за поставку новых фичей, как и все остальные. Именно поэтому недостаточно нанять некого DevOps-инженера (название культуры-инженер, серьёзно? Кто это придумал?), для этого нужны T-shape сотрудники во всех направлениях.