Ускоряйся! Наука DevOps - страница 2

Дело не в том, что культуры ИТ-компаний становятся доминирующими в корпоративной среде. Важно, что технологическая платформа – ее циклы развития, потребности, архитектура, эффективность – предопределяет и организационную структуру бизнеса, и профиль сотрудника с точки зрения его компетенций и ценностей.

Но что, если цифровая платформа устарела, перегружена и не справляется с растущим потоком данных? Именно это и происходит сегодня в большинстве российских компаний. Старые ИТ-системы с трудом и медленно меняются, слабо защищают от киберугроз и санкционных рисков. Вместо того чтобы стать основой трансформации бизнеса, они тормозят его развитие.

На мой взгляд, единственный способ преодолеть технологические ограничения сегодняшнего дня – создавать принципиально новые ИТ-платформы. Их основой должны стать достижения цифровой эпохи: передовые архитектуры, революционные технологии, прогрессивные подходы к управлению. Я уверен, что книга «Ускоряйся!» будет полезна каждому, кто твердо решил встать на путь к свободе цифрового развития.

Несколько лет назад я прочитал отчет, в котором говорилось: «Теперь мы можем с уверенностью утверждать, что высокая эффективность ИТ коррелирует с высокой эффективностью бизнеса, помогая увеличить производительность, прибыльность и долю рынка». Когда я читаю что-то подобное, моя первая реакция – со всей силы швырнуть это в мусорное ведро, потому что такие слова обычно говорят о какой-то высосанной из пальца ерунде, маскирующейся под науку. Однако на этот раз я заколебался, потому что у меня в руках был «Отчет о состоянии DevOps за 2014 год». Одним из его авторов был Джез Хамбл, мой коллега и друг, у которого, как я знал, тоже была аллергия на подобную чепуху. (Хотя я должен признаться, что еще одной причиной, по которой я не бросил его, было то, что я читал его на своем iPad.)

Вместо этого я отправил Джезу письмо по электронной почте, чтобы узнать, что стоит за этим заявлением. Несколько недель спустя я созвонился с ним и Николь Форсгрен, которая терпеливо ввела меня в курс дела. Хотя я не эксперт по методам, которые они использовали, она сказала достаточно, чтобы убедить меня, что здесь речь идет о реальном анализе, гораздо большем, чем я обычно вижу даже в научных работах. Я следил за последующими отчетами о состоянии DevOps с интересом, но и с растущим разочарованием. Отчеты представляли результаты их работы, но никогда не содержали тех подробных объяснений, которые Николь дала мне во время телефонного разговора. Это сильно подорвало к ним доверие, поскольку было мало доказательств того, что эти отчеты основаны на чем-то большем, чем просто гипотезы. Наконец, те из нас, кто уже «побывал за кулисами», убедили Николь, Джеза и Джина раскрыть свои методы, написав эту книгу. Для меня это было долгое ожидание, но теперь я рад, что у меня есть то, что я могу искренне рекомендовать как способ взглянуть на эффективность доставки ИТ-решений, основанный на чем-то большем, чем разрозненный опыт нескольких аналитиков.

Картина, которую они нарисовали в своей книге, просто неотразима. Они описывают, как компаниям с эффективными ИТ-доставками требуется около часа, чтобы довести код от «сохранения в магистраль» (committed to mainline) до «запуска в производство», – путь, который в некоторых организациях занимает месяцы. Таким образом они обновляют свое программное обеспечение много раз в день, а не один раз в несколько месяцев, увеличивая свою способность использовать программное обеспечение для изучения рынка, реагирования на события и выпуска новых функций быстрее, чем конкуренты. Такое огромное увеличение быстродействия не связано с затратами на стабильность, так как эти организации обнаруживают, что их обновления вызывают сбои, быстрее их менее эффективных коллег и эти сбои обычно фиксируются в течение часа. Их доказательства опровергают бимодальное представление о том, что вам нужно выбирать между скоростью и стабильностью, – напротив, скорость зависит от стабильности, поэтому хорошие ИТ-практики дают вам и то и другое.