Все это требовалось, чтобы превратить 3 отдела (Dev, QA, Ops) в одну структуру, работающую как часы. Вдохновленные историей про 10 релизов в день, люди стали придумывать разные методы достижения этой цели. Выделились 2 аспекта: технологический и организационный.

Что касалось техники, то тут все было более менее просто. И у инженеров, и у разработчиков уже были необходимые инструменты для работы, оставалось только их “подружить”. Так, например, инженеры стали хранить свои скрипты в системе контроля версий, а разработчики отправлять логи не локально, а на централизованное хранилище (как logstash). Стали совершенствовать мониторинг приложений с помощью отправки метрик, выделять конфиги приложения и держать их в отдельном месте, добавлять в приложения API для проверки работоспособности.
Микросервисная архитектура позволила упростить релизы и ликвидировать центральную точку отказа. CI/CD автоматизировал полную цепочку от коммита до развертывания в staging (а иногда и в prod). Amazon и прочие облачные провайдеры становился все популярнее, вышел Docker, а вслед за ним Kubernetes и Mesos, популярные сервисы для разработки Jira, Slack, Github и т.д. стали теснее интегрироваться друг с другом - медленно, но верно, наступала технологическая ИТ утопия.

С организационной точки зрения дела шли чуть похуже. Не смотря на то, что DevOps подразумевал совместную работу 3 разных ролей, большинство контор формировало отдельные группы DevOps - специалистов, отвечающих за весь спектр DevOps инструментов.
Такой подход не только не помогал, но и мешал: главной целью DevOps было уничтожить так называемые “silo” - роли с ограниченным доступом и зоной ответственности. Хуже всего было то, что разработка и эксплуатация не всегда могли “синхронизироваться” из-за разных методов управления проектами. Если разработка была проактивной и пыталась “доставить” определенный функционал за “спринт”, то Ops оставался реакционным и реагировал на входящие тикеты от разработки, по сути превратившись в helpdesk для разработчиков.