Читати книгу - "ХЗ. Хто знає, яким буде майбутнє"

на різних підрядників (до розробки сайту healthcare.gov залучили 33 компанії і підписали 60 різних угод144), з’ясовували, що користувалися різними системами відстеження робочих завдань. Виходило, що команди розробників надсилали запити в нікуди й марно сподівалися, що колеги виконають завдання. Не розуміючи взаємозалежності, учасники процесу зайшли в глухий кут: кожна команда, не в змозі продовжувати, чекала результатів від іншої.

За рахунок веб-сервісів, API, систем відстеження робочих завдань чи багів схема роботи «Обіцяні результати» в будь-якому разі забезпечує належний рівень автономності працівників. Адже кожний автономний учасник процесу особисто дає обіцянки і відповідає за їхнє виконання.

Усі — всередині програми

Новий підхід до розробки програмного забезпечення вплинув і на роботу компаній. Раніше метою девелоперів був кінцевий продукт: скажімо, «вихідний еталон» наступної версії Microsoft Windows, яку розробляли протягом кількох років, а в день випуску заливали на мільйони CD-ROM і розповсюджували серед десятків тисяч роздрібних продавців і корпоративних клієнтів. Та згодом розробка софту стала безперервним процесом, спрямованим на поступове вдосконалення продукту.

Добре пам’ятаю слова Марка Луковскі, колишнього провідного інженера Microsoft, про те, як змінилася його робота після переходу в Google: «Я щось змінюю і відразу скидаю оновлення мільйонам користувачів онлайн». Марк говорив про кардинальну трансформацію в розробці ПЗ за доби хмарних технологій. Жодних «вихідних еталонів». Нині софт завжди в розробці, програмісти крок за кроком вносять значні чи незначні зміни. Із погляду компанії, яка надає послуги онлайн, софт перетворився з продукту на процес, а врешті й на потік бізнес-операцій. Ті операції треба оптимізовувати не тільки для девелоперів софту, а й для користувачів, бо ті запускають програми, які оновлюються мало не щодня.

Тепер компанія — гібридний організм, сформований із людей і машин. Я поділився цією ідеєю зі співробітниками Amazon 2003 року. Розповів їм про механічного турка, який грав у шахи. Автоматизованого шахіста сконструював Вольфґанґ фон Кемпелен. Наприкінці XVIII — на початку XIX століття диво показували по всій Європі. Турок дивував і перемагав таких видатних людей, як Наполеон і Бенджамін Франклін. Насправді ж робот був ілюзією: усередині ховався справжній чемпіон із шахів; спеціальні лінзи дозволяли бачити дошку, а важелі — рухати руками «автоматизованого» гравця. На мою думку, це чудова метафора для аналізу нового покоління веб-додатків.

Співробітникам Amazon я нагадав: програми — не просто софт, а ще й стрімкий потік контенту, який безперервно створює мережа постачальників і підтримується відгуками, рейтингами та іншими видами зворотного зв’язку з широкою мережею клієнтів. Усі поповнення контенту форматуються, обробляються й розширюються зусиллями персоналу компанії (редакційні огляди, оновлення, програмування). Динамічним потоком контенту щодня управляють працівники Amazon. Пригадую, я сказав слухачам: «Усі ви — програмісти, дизайнери, контент-менеджери, менеджери продукту, покупці, представники служби підтримки клієнтів — усередині програми».

Пізніше я собі гадав, що, розповівши ту історію на лекції, надихнув творців служби Amazon Mechanical Turk (Механічний турок), яка за допомогою краудсорсингової мережі працівників виконує дрібні, але складні для комп’ютерів, завдання. Та, виявилося, хоч служба запрацювала 2005 року, заявку на відповідний патент Amazon подала ще 2001-го (щоправда, отримала патент лише 2007-го). Принаймні я сподіваюся, що підказав компанії влучну назву, а запатентували розробку за назвою «Хунта»145.

До ідеї про те, що, розробляючи інтернет-сервіси, девелопери перебувають «усередині програми», я дійшов поступово. Спершу намагався зрозуміти, чому програмування мовою Perl так багато важило в часи зародження веб-технологій.

Пам’ятаю, я запитав Джеффрі Фрідла, автора книжки «Регулярні вирази» (Mastering Regular Expressions), яку ми видали 1997 року, як він застосовує Perl, працюючи в Yahoo!. Він відповів: «Я щодня пишу регулярні вирази, узгоджуючи інформаційні повідомлення з тікерами, щоб можна було їх розміщувати на відповідних сторінках finance.yahoo.com». (Регулярні вирази — це своєрідні шаблони пошуку з метасимволами, ніби накачані стероїдами. Така собі фіча мови програмування, яка дозволяє зіставляти будь-які стрічки (strings) тексту магічним чином — принаймні таке враження складається в необізнаних). Тоді мене осяяло: та ж Джеффрі — не менш важливий елемент finance.yahoo.com, ніж скрипти Perl, які він пише. Джеффрі не може написати їх один раз і забути. З огляду на динамічні особливості контенту, який відображається на сайті, розробники мають змінювати програми щодня.

До того часу, коли мене запросили виступити в Amazon 2003 року, я добре обміркував ідею і збагнув, що всі працівники компанії, та й усі учасники широкої мережі (від постачальників до клієнтів, які пишуть відгуки і визначають рейтинги товарів), є елементами програми.

Лише 2006 року, коли Amazon, Microsoft та інші компанії починали розуміти можливості хмарних обчислень, нова парадигма набула чіткіших обрисів. Дебра Чрапаті, тодішня віце-президентка поточної діяльності інтернет-провайдера Microsoft Network (MSN), влучно окреслила зміни: «Невдовзі девелопер тієї чи іншої платформи буде елементом, розміщеним на ній, або частиною її інфраструктури». Дебра пояснила, що має конкурентні переваги, розміщуючи дата-­центри в місцях, де можна заощадити на електроенергії.

Після нашої розмови я опублікував пост в інтернеті: «Операції: новий секретний соус» (Operations: The New Secret Sauce)146. Мої міркування сподобалися Джессі Роббінсу, тодішньому «майстрові катастроф» Amazon. Джессі мав оригінальні обов’язки: порушувати роботу команд компанії, щоб вони виробляли стійкість до диверсій. Джессі розповів, що, так само як багато колег, роздрукував мій пост і повісив на робочому місці. Він тішився: «Нарешті хтось сказав, що ми важливі».

За рік Джессі разом зі Стівом Саудерсом з Yahoo!, Енді Оремом з O’Reilly Media та Артуром Берґманом, директором із розвитку сервісу Wikia, попросили мене організувати зустріч. «Нам потрібне місце для зборів нашої братії», — сказав Джессі. Я охоче погодився. На саміті ми зібрали провідних фахівців нової сфери діяльності — веб-операцій. Згодом започаткували конференцію Velocity, бо дедалі більше людей «за лаштунками» сприяли швидшому та ефективнішому функціонуванню сайтів. На нашій конференції збиралися люди, які працювали в новому напрямку — DevOps (скорочення від англійських слів: development (розробка) й operations (операції)). За кілька місяців після першої конференції Velocity термін DevOps ввели в обіг Патрик Дебуа та Ендрю «Клей» Шафер, які проводили серію зустрічей DevOps Days у Бельгії.

Новизна DevOps полягала в наступному. Традиційно