Тим О'Райли - WTF? Гид по бизнес-моделям будущего [litres]

В течение долгого времени я задавался вопросом, мог ли тот мой рассказ вдохновить Amazon на создание площадки Amazon Mechanical Turk, использующей коллективный труд сети работников для выполнения небольших задач, которые являются трудновыполнимыми для компьютеров. Впрочем, хоть сервис и был запущен в 2005 году, заявка на его патент была подана в 2001 году. Правда, он был выдан только в 2007-м, поэтому в лучшем случае я мог вдохновить на название.

Моя идея о том, что в Интернете программисты находятся «внутри приложения», развивалась постепенно. Впервые она пришла мне в голову, когда я пытался понять, почему язык программирования Perl стал таким важным в первые дни Интернета.

Мне особенно запомнился один разговор. Я спросил Джеффри Фридла, автора книги «Регулярные выражения» (издательство «Символ-Плюс», 2008 г. – Прим. ред. ), которую наше издательство опубликовало в 1997 году, что же такое он сделал с Perl на своей основной работе в Yahoo!. «Целыми днями я писал регулярные выражения, чтобы они соответствовали новым историям с тикерными символами, а мы могли показывать их на соответствующих страницах finance.yahoo.com», – ответил он. (Регулярные выражения похожи на подстановочные знаки на стероидах – функция языка программирования, которая позволяет сопоставлять любую строку текста, что для непосвященных кажется магическим заклинанием.) Мне сразу стало ясно, что сам Джеффри был такой же частью finance.yahoo.com, как и написанные им скрипты Perl, потому что он не мог просто один раз написать их и уйти. Поскольку веб-сайт пытался отразить динамичный характер контента, ему нужно было каждый день изменять свои программы.

К моменту своего выступления в Amazon в 2003 году я развил эту мысль и понял, что и все сотрудники компании, и участники расширенной сети, от поставщиков до клиентов, оставляющих отзывы и дающих оценку продукции, были частью приложения.

Но только в 2006 году, когда такие компании, как Amazon и Microsoft, начали понимать возможности облачных вычислений, этот еще один важный элемент оказался в центре внимания. Я беседовал с Деброй Храпаты, которая была в то время вице-президентом по оперативной деятельности компании Microsoft Network. Ее проницательный комментарий полностью отражал перемены: «В будущем быть разработчиком на чьей-либо платформе будет означать обосноваться в их инфраструктуре». В качестве примера она рассказала о конкурентном преимуществе, которое она создавала, размещая свои центры обработки данных там, где энергия была дешевой.

Статья, которую я написал после нашей беседы, называлась «Оперативная деятельность: новый секретный соус». В ней много места уделялось рассказу о Джесси Роббинсоме, в то время «мастеру-ломастеру» компании Amazon, чья работа заключалась в том, чтобы подрывать деятельность других команд, заставляя их становиться более жизнеспособными. Он сказал мне, что он и многие его коллеги распечатали мою статью и повесили ее на стенах рядом со своими рабочими местами. «Впервые кто-то сказал, что мы важны».

В следующем году Джесси, Стив Саудерс из компании Yahoo! Энди Орам из O’Reilly Media и Артур Бергман, главный технический директор Wikia, попросили меня о встрече. «Нам нужна площадка, где наша компания могла бы собраться вместе», – сказал мне Джесси. Я с радостью согласился. Мы организовали саммит с лидерами зарождающейся области обслуживания веб-сайтов и вскоре после этого организовали конференцию Velocity для растущего числа профессионалов, работавших за кулисами, заставляя интернет-сайты работать быстрее и эффективнее. На конференции Velocity собралось сообщество, работающее над новой дисциплиной, получившей название DevOps, акроним от англ. development и operations – «разработка и обслуживание программного обеспечения». (Этот термин был придуман через несколько месяцев после первой конференции Velocity Патриком Дебуа и Эндрю «Клей» Шафером, которые провели серию встреч под названием «Дни DevOps» в Бельгии.)

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

DevOps – это способ увидеть весь жизненный цикл программного обеспечения, аналогично процессу «бережливого производства», которое определила для себя корпорация Toyota. DevOps берет жизненный цикл программного обеспечения и процесс работы интернет-приложения и превращает их в процесс работы организации, измеряя показатели, находя слабые места и определяя необходимые средства связи.

В дополнении к учебному пособию по DevOps, написанному в виде романа «Проект Феникс» Джином Кимом, Кевином Бером и Джорджем Спаффордом (изд. «Эксмо», 2015 г. – Прим. ред. ), воздавшему дань уважения знаменитому роману о принципах бережливого производства «Цель» (очевидно, речь о книге Э. М. Голдратт и Дж. Кокс, Альпина Паблишер, 2014 г. – Прим. ред. ), Джин Ким отмечает, что скорость является одним из ключевых конкурентных преимуществ, которые дает организации DevOps. Обычное предприятие может выпускать новое программное обеспечение раз в девять месяцев, а период его освоения может занять от одного до трех месяцев. В таких компаниях, как Amazon и Google, выпускаются тысячи крошечных обновлений, а время их освоения измеряется в минутах. Многие из этих обновлений обладают экспериментальными функциями, которые можно отыграть назад или изменить.

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

Большая часть этой работы полностью автоматизирована. Хал Вариан называет это «компьютерным кайдзеном», ссылаясь на японский термин, обозначающий непрерывное совершенствование. «Точно так же как массовое производство изменило метод сборки продукции, непрерывное совершенствование изменило то, как осуществляется производство, – пишет он, – непрерывное экспериментирование… улучшает оптимизацию бизнес-процессов в наших организациях».

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