Стратегическое решение, принятие которого не заметили: право «не знать»

В прошлом тексте (“Как отличить Инженерию от её симуляции”) речь шла о трёх вопросах, по которым инженерию можно отличить от деятельности, внешне на неё похожей. Граница между ними проходит не по должностям и не по стеку, а по тому, строится ли работа на модели устройства системы, которую проверяют раньше, чем её проверит эксплуатация. Из этого различения вытекает вопрос, который выходит за рамки темы прошлой статьи и заслуживает отдельного разбора: если симуляцию можно отличить так просто, то почему она годами живёт в крупных и вполне успешных компаниях?

Отчасти потому, что катастрофы, к которым она ведёт, бывают двух видов. Одни наблюдаются публично: масштабный сбой с длительным простоем и крайне негативным влиянием на бизнес бьёт по репутации и для владельцев работает как жёсткая, но честная обратная связь. Другие публично не наблюдаются и годами тянутся во внутреннем контуре компании в виде сдвигающихся сроков, повторяющихся инцидентов и растущих бюджетов, причём каждый такой эпизод выглядит как локальный дефект конкретного элемента системы: СХД, подрядчика, очередного релиза. Поэтому системный дефект, из которого растут катастрофы второго вида, от владельца оказывается скрыт, причём не обязательно намеренно: он просто разложен на череду частных объяснений, каждое из которых по отдельности правдиво.

Отсюда и объём этого текста: ответ на вопрос дан на примере именно такого системного дефекта, трудного к распознанию, поэтому все доводы в нём развёрнуты, а выводы произнесены целиком, тогда как методик обнаружения простых дефектов и без того достаточно.

Сам этот системный дефект за последний год я наблюдал неоднократно, хотя описание его держится не на наблюдениях, а на устройстве самих вещей, и связан он с тем, в каком месте находится инженерия, результатами которой пользуется компания. Когда инфраструктура компании размещена в облаке, инженерия находится в двух местах: инженерия нижних уровней у провайдера, инженерия верхних уровней у самой компании, а граница между ними задаётся моделью услуги. В IaaS у провайдера остаются только нижние уровни (площадки, сеть, хранение, виртуализация), а операционные системы виртуальных машин, базы данных и всё, что выше, компания администрирует сама, тогда как в PaaS и SaaS у провайдера оказывается большая часть уровней, вплоть до баз данных, очередей и объектных хранилищ. На уровнях, отданных провайдеру, компания видит результаты работы его инженерии, например задержку ввода-вывода слоя хранения, а саму модель устройства, с помощью которой инженеры провайдера эти результаты предсказывают и обеспечивают, видит в лучшем случае фрагментами в публичных разборах инцидентов и не может проверить её на собственных отказах. Собственная (on-premise) инфраструктура может размещаться в собственном ЦОДе, на арендованных стойках у колокейшн-провайдера или на нескольких площадках сразу, но в любом из этих вариантов каждая её часть держится на модели устройства, которая должна быть одновременно и в команде, эксплуатирующей инфраструктуру, и в продуктах, на основе которых построена эта часть инфраструктуры: вендор инфраструктурного продукта может заложить в него модель его внутреннего устройства, но модель того, как продукты собраны в систему и как эта система ведёт себя при отказах, остаётся за командой, эксплуатирующей инфраструктуру.

В определённый момент некоторые компании, годами жившие в публичном облаке, решают мигрировать инфраструктуру из облака в on-premise. Решение это бывает вполне экономически обосновано, счёт за облако к этому моменту порой уже заметно сокращён, отчёты по проекту миграции зелёные, и тем не менее сроки сдвигаются из квартала в квартал, причём у каждого сдвига есть убедительные объяснения. Объяснения эти, как правило, правдивы, но описывают симптомы. За ними стоит обстоятельство, которое не нужно доказывать статистикой, потому что оно следует из самого устройства облака: миграция требует инженерии каждого уровня, отданного провайдеру, сразу в двух местах, в исходной облачной инфраструктуре, где она есть у провайдера, и в целевой собственной (приёмнике), где её должны обеспечить одновременно и команда, эксплуатирующая инфраструктуру, и вендор, заложивший модель устройства в продукты, из которых приёмник собран. При этом годы жизни в облаке не дают компании ни одного способа достоверно узнать из собственного опыта, будет ли для приёмника модель устройства одновременно и в команде, эксплуатирующей инфраструктуру, и в продуктах, поскольку все отказы этих уровней, которые могли бы это показать, приходились на модель провайдера, а таких уровней тем больше, чем дальше компания ушла от IaaS к PaaS и SaaS. И вот без проверки того, есть ли в приёмнике модель устройства и в команде, и в продуктах, миграция напоминает переливание воды из одного ведра в место, где должно было стоять второе ведро, но ведра там нет, поэтому вода льётся прямиком в планету.

Что облако предоставляло вместе с услугами

Когда компания покупает услугу “объектное хранилище”, она получает не только место для объектов, но и обещание: записанные объекты удастся прочитать, даже если откажет диск, сервер, стойка или целый машинный зал, и обычно это обещание выражено в девятках долговечности в SLA или описании сервиса. В терминах прошлого текста за обещанием стоит модель устройства, то есть знание о том, как устроены домены отказа, сколько копий или фрагментов нужно и где их размещать, сколько длится восстановление после отказа и что происходит с объектами в это время. Существеннее другое: за обещанием стоит ответственность провайдера за последствия, и когда откажет диск, стойка или зал, на реальном отказе будет проверяться модель провайдера, а не модель клиента. Клиенту всё это знать не нужно по построению, и в этом состоит услуга: облако предоставляет право “не знать” того, что происходит на отданных провайдеру уровнях, закреплённое в SLA или описании сервиса. В облаке это право совпадает с возможностью “не знать”, то есть пользоваться результатами инженерии, не видя целиком модели устройства, с помощью которой инженеры провайдера эти результаты предсказывают и обеспечивают, потому что за правом стоит инженерия провайдера, а цена знания (людей, которые его держат, стендов, на которых его проверяют, инцидентов, на которых его пополняют) растворена в цене гигабайта.

За годы жизни в облаке организация, как правило, перестраивается вокруг этого права, причём совершенно рационально и тем глубже, чем больше уровней отдано провайдеру. Нанимаются и растут люди, умеющие быстро выпускать и запускать сервисы на готовой платформе, а не разбираться в том, как хранение данных устроено на физическом уровне; карьерные лестницы строятся из ролей, нужных для работы в облаке, а роли, отвечающие за нижние уровни (хранение, сеть, площадки), из них постепенно исчезают, поскольку эти уровни держит провайдер; экономика инфраструктуры сводится к управлению счётом, и его снижение (то, что сейчас принято называть FinOps) даёт вполне ощутимую экономию. Однако вся эта экономия достигается внутри системы, где провайдеру принадлежит не только знание о рисках хранения, но и сама инженерия отданных ему уровней: оптимизация счёта улучшает то, как компания пользуется правом “не знать”, но ничего не меняет в самом праве. По сути, право “не знать” является стратегическим решением, принятие которого не заметили: из него следует, какие способности будут у компании через годы, а каких не будет, от кого она будет зависеть и во что обойдётся любая смена направления, включая миграцию из облака.

Миграция инфраструктуры из облака в on-premise это право не отменяет, но место облачного провайдера в нём занимают вендоры инфраструктурного ПО и оборудования (платформ виртуализации, программно-определяемых хранилищ, СХД), а право и возможность “не знать” после этого перестают совпадать. Право, закреплённое в договоре с таким вендором, подкреплено возможностью только в пределах внутреннего устройства тех продуктов, в которые вендор действительно заложил модель, и только при условии, что команда знает, как эти продукты ведут себя на своих границах, в штатном режиме и при отказе. Всё, что лежит за этими пределами, включая то, как продукты собраны в систему, превращается в обязанность знать, которую может выполнить только инженерия команды, эксплуатирующей эту инфраструктуру. Но прежде чем посмотреть, что именно возвращается в компанию вместе с железом, стоит понять, почему за годы жизни в облаке вопрос о том, есть ли инженерия у самой компании, обычно не возникал в проверяемой форме.

Почему в облаке не видно, есть ли инженерия у самой компании

В облаке право “не знать” и возможность “не знать” совпадают на тех уровнях, которые отданы провайдеру, и механизм здесь довольно простой. В прошлом тексте инженерия определялась тремя свойствами: у неё есть модель механизма, из которой следуют проверяемые предсказания; последнее слово в ней принадлежит самой системе; она опровержима по механизму, то есть способна сказать, почему система упала, и предсказать, когда упадёт снова. На уровнях, отданных провайдеру (в IaaS это площадки, сеть, хранение и виртуализация, в PaaS и SaaS к ним добавляются базы данных, очереди, объектные хранилища, ПО общего назначения и т.п.), инженерия именно этих уровней находится на стороне провайдера. Модель механизма принадлежит ему, разбор причин и предсказание повторяемости инцидентов ведут его инженеры, а когда на этих уровнях что-то отказывает, на реальном отказе проверяется именно модель провайдера, а не модель клиента. Последствия таких отказов переданы провайдеру, в том числе юридически, и закреплены в SLA или описании сервиса: это его хранилище теряет или не теряет подтверждённые записи, его механизмы резервирования срабатывают или не срабатывают. Уровни, оставшиеся на стороне клиента, лежат выше, и последствия отказа на них уже зависят от модели услуги: в PaaS и SaaS такой отказ обходится компании дорого (простоем сервисов и потерянной выручкой), но от потери данных из-за отказов оборудования и платформы компанию чаще всего защищает провайдер, а в IaaS, где ПО компания администрирует сама, аналогичной защиты для данных этого ПО услуга не подразумевает.

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

Отсюда и главная ловушка: изнутри компании модели устройства уровней, которые в облаке были отданы провайдеру, не видно в обоих случаях, но по противоположным причинам. В облаке её не видно потому, что она находится на стороне провайдера, а компания получает только результаты работы его инженерии (данные не теряются, отказы отдельных элементов не становятся фатальными благодаря работающим механизмам резервирования, причины разобраны). В собственной инфраструктуре её может быть не видно потому, что для какой-то части этой инфраструктуры модель устройства не находится одновременно и в команде, которая эту часть эксплуатирует, и в продукте, на основе которого эта часть построена. Эти два отсутствия наблюдения внешне тождественны, а по существу противоположны, и в опыте эксплуатации компании, годами жившей в облаке, нет ничего, что позволило бы отличить одно от другого, если не задавать себе вопросов из прошлого текста. Местами отсутствие видимой модели устройства и вовсе становится нормой вида “так всегда было”: раз все эти годы модели устройства не было видно, а данные при этом не терялись, значит, так и должно быть (а то и вовсе: данные не терялись именно потому, что никакой инженерии и не требовалось). Поэтому привычка пользоваться правом “не знать” без всякого умысла переносится туда, где возможность “не знать” достоверно не выяснена.

Похожий механизм я описывал в апреле применительно к дешёвому капиталу: пока капитал был дешёвым, компаниям не требовалось проверять, соответствует ли заявленное реальному, а после удорожания капитала такая проверка стала необходимой. С облачной инфраструктурой происходит примерно то же самое, с одной, но существенной разницей: необходимость проверки отпадала не из-за денег, а потому, что инженерия отданных уровней находилась у провайдера и за неё по SLA или описанию сервиса отвечал он. При миграции инфраструктуры из облака в on-premise проверка становится необходимой так же неизбежно. Последствия отказов диска, стойки или площадки, которые годами ложились на провайдера, теперь ложатся на саму компанию, и выдерживает ли их её собственная модель устройства, окончательно покажет только эксплуатация с реальными инцидентами.

Где теперь проявятся последствия отказов

После миграции инфраструктуры из облака в on-premise отказы, за последствия которых раньше по SLA или описанию сервиса отвечал провайдер, никуда не исчезают, но оборачиваются неожиданными проблемами прежде всего там, где модель устройства не находится одновременно и в команде, и в продукте. Это условие проверяется прежде всего на трёх задачах, и в каждой из них то, что в облаке было заботой провайдера или вовсе не возникало, становится утверждением компании о собственной системе, которое либо проверено, либо принято на веру.

Первая из этих задач состоит в самой миграции инфраструктуры из облака в on-premise, масштаб которой хорошо виден на простом примере. Возьмём для круглого счёта 10 ПБ данных: при реальной загрузке канала 100 Гбит/с одно только их копирование займёт около двух недель, а по каналу 10 Гбит/с не меньше трёх месяцев. Однако копирование составляет лишь первую часть миграции: пока данные копируются, система в облаке продолжает работать и записывать новые данные, поэтому копия в собственной инфраструктуре остаётся актуальной только тогда, когда накопившиеся изменения переносятся в неё по ходу, например механизмами передачи дельт. Значит, до момента переключения обе копии нужно синхронизировать, и всё это время данные компании существуют в двух местах одновременно, в облаке и в собственной инфраструктуре. Утверждение о том, что обе копии идентичны, требует проверки, и отказаться от облака до получения однозначных результатов такой проверки без риска нельзя. Поэтому период, когда компания платит одновременно и за облако, и за собственную инфраструктуру, снизу ограничен скоростью канала, а сверху определяется тем, умеет ли компания однозначно определить и проверить идентичность данных. Растягивается из квартала в квартал именно вторая часть: если идентичность не проверяется в любой момент, а лишь принимается на веру, то с некоторой вероятностью расхождения обнаружатся уже после переключения, и из-за них миграцию придётся откатить на шаг назад.

Вторая задача состоит в том, чтобы обеспечить инженерию каждой составляющей собственной инфраструктуры: вычислительных узлов и платформы виртуализации, сети, инфраструктуры хранения (SAN, NAS или программно-определяемого хранилища). Для каждой из них модель устройства должна быть одновременно и в продукте, и в команде: вендор может знать, как его СХД или платформа виртуализации ведут себя при отказе диска, узла или контроллера, но только команда может знать, что произойдёт со всей системой, когда отказ в хранении совпадёт с отказом вычислительного узла или с потерей одного из сетевых путей. Нагляднее всего это видно на хранении данных, где выбор схемы избыточности определяет, от чего данные на самом деле защищены (от отказа отдельных дисков, целого сервера или СХД, целой площадки), сколько дней после отказа они живут с уменьшенной избыточностью и как меняется производительность: одни схемы медленнее записывают данные уже в обычный день, другие заметно проседают, пока идёт восстановление после отказа, и эта просадка приходится ровно на то время, когда данные и без того защищены хуже обычного, а системы, которые эти данные используют, продолжают работать под полной нагрузкой. То же относится к вычислениям и сети: механизм высокой доступности, который после потери связи с узлом перезапускает его виртуальные машины на другом узле, без надёжной изоляции отказавшего узла может запустить вторую копию машины, пока первая, на самом деле живая, продолжает писать на общий том, и тогда отказ одного узла превращается в порчу данных (это не изъян какого-то одного продукта: механизм описан в документации разных платформ виртуализации [1], [2]), а резервный сетевой путь, ни разу не проверенный под нагрузкой, может оказаться не резервом, а предположением. Если модель устройства не находится одновременно и в команде, и в продукте, каждое такое утверждение остаётся принятым на веру до первого совпадения отказов.

Третья задача связана с отказоустойчивостью между площадками, которая нередко интуитивно воспринимается так, будто две площадки сами по себе защищают от потери любой из них. Однако при разрыве связи между площадками у системы нет универсального способа самостоятельно определить, отказала ли вторая площадка или только канал до неё. Поэтому для данных, которые не допускают расхождения копий (платежи, остатки, заказы), выбор здесь невелик. Либо одна из площадок заранее назначается главной и продолжает работу, и тогда потеря именно главной останавливает всё. Либо решение о том, какая площадка продолжит работу, принимает человек, беря на себя риск того, что обе половины начнут принимать записи независимо друг от друга. Либо в схему добавляется третий голос (арбитр на третьей площадке), который и позволяет системе пережить потерю любой из двух площадок автоматически. Данные, допускающие последующее слияние расхождений, могут приниматься на обеих площадках сразу, но за это приходится платить сложностью слияния, которое кто-то должен уметь не только спроектировать, но и реализовать без отклонений от проекта. Наконец, при синхронной репликации разнесение площадок подальше друг от друга замедляет каждую запись тем сильнее, чем дальше они разнесены, а при асинхронной запись не замедляется, но при аварии теряются последние подтверждённые записи. Поэтому утверждение “у нас две площадки, значит, мы отказоустойчивы” без уточнения, какой вариант выбран и какой ценой, остаётся правдоподобным ровно до первой аварии.

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

Почему культура здесь не помогает

Все три задачи требуют модели устройства собственной системы, а значит, инженерии, в которой такая модель строится и проверяется. Пока инфраструктура находилась в облаке, инженерия этих уровней была у провайдера, в зоне его ответственности, и самой компании иметь её не требовалось, а дорогое и невидимое, без чего можно обходиться, рано или поздно попадает под нож экономии, тогда как дешёвые и видимые формы под этот нож не попадают. Поэтому у компании, годами жившей в облаке, может не оказаться ни предметного знания о поведении собственной системы, ни, что существеннее, людей, практикующих инженерию как способ работы, который позволил бы получить это знание заранее, а не тогда, когда компания уже владеет собственной инфраструктурой и отвечает за каждый её отказ сама. Причина не в том, что люди плохи или неопытны: предметное знание появляется только там, где есть требующие его задачи, а задачи нижних уровней, вычислений, сети и хранения данных, за компанию годами решал провайдер. Платформенная команда знает поставку и запуск сервисов, прикладные команды отлично знают нюансы функционирования своих сервисов, однако на вопрос “что произойдёт с данными, если в среду в 14:00 погаснет вторая площадка, пока ещё идёт восстановление после отказа диска в понедельник” внутри компании целиком не может ответить никто. До миграции у провайдера был не только ответ на такой вопрос, но и сам вопрос: внутри компании его годами просто некому и незачем было задавать.

Здесь важно развести две вещи, которые при миграции легко спутать: инженерию как способ работы и предметное знание о поведении конкретных систем. Предметного знания о петабайтном хранилище у компании, жившей в облаке, может не быть и при наличии инженерии: человек, пять лет проработавший с платформой поставки в облаке, вырастает в сильного руководителя платформы поставки, но поведение петабайтного хранилища при отказе двух компонентов разных уровней в его практике могло не встречаться ни разу. Такая нехватка поправима там, где работают инженеры, практикующие инженерию как способ работы, устроенный вокруг неизбежности неполноты знания: они создают тестовые стенды, проверяют утверждения раньше, чем их проверит эксплуатация, и интегрируют неучтённое знание в модель раньше, чем это сделает Его Величество Случай. Культурой не поправить другое, поскольку культура передаёт формы, а способ работы формой не является. Всё время жизни в облаке организация полагалась на свою инженерную культуру, подразумевая, что за ней стоит собственная инженерия (раз культура “инженерная”, то ведь тогда должна быть и сама “инженерия”), тогда как результаты, которые компания принимала за плоды своей инженерии, обеспечивала инженерия провайдера. Под самой культурой, если артефакты компании не проходят три проверки прошлого текста, находится пустое место (если говорить языком баз данных, NULL). В этом случае то, чего компания не знает о собственной инфраструктуре, не находится заранее на стендах и не попадает в отчёты, поэтому отчёты показывают, что миграция идёт по плану, а само незнание проявляется только в реальных инцидентах эксплуатации. Граница, как и в прошлом тексте, проходит не по возрасту, не по должности и не по объёму знаний, а по тому, практикуют ли люди в компании инженерию как способ работы.

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

Из различения двух вариантов отсутствия инженерии (при эксплуатации инфраструктуры в облаке и в формате on-premise) вытекает и проверяемое следствие для самих миграций, а именно утверждение о причине, по которой сдвигаются их сроки. Статус этого утверждения стоит назвать прямо: это гипотеза, а не вывод из различения. Гипотеза состоит в том, что сроки миграции инфраструктуры из облака в on-premise сдвигаются из квартала в квартал прежде всего там, где для уровней, которые в облаке держал провайдер, в целевой инфраструктуре модель устройства не находится одновременно и в команде, и в продуктах, а технические объяснения в отчётах описывают лишь симптомы этой причины. Гипотеза опровержима так же, как любое инженерное утверждение, и для её проверки не нужна вторая компания рядом: у каждой компании провайдеру отдан свой, уникальный набор уровней, поэтому сопоставимой второй компании может просто не найтись, а сравнивать можно уровни внутри одной компании. Достаточно до начала миграции записать для каждого такого уровня, есть ли модель устройства и в команде, и в продукте. В команде это видно по тому, что её артефакты проходят три проверки прошлого текста: у метрик проверена связь с предметом, у утверждений о системе названы условия ложности, а реакции на отклонения проходят проверку на выход за границу присущего разброса (а не по тому, что компания сама считает, что инженерия у неё есть). В вендорском продукте это видно по тому, что штатная эксплуатация его инсталляций и типовые отказы обходятся без участия людей вендора, а коммерческая поддержка, в том числе на площадке заказчика, нужна для исключительных случаев, и её объём не растёт пропорционально числу инсталляций. Гипотеза предсказывает, что сдвиги сроков придутся прежде всего на те уровни, где модель устройства не оказалась одновременно и в команде, и в продукте. Если же сдвиги распределятся по уровням независимо от того, находилась ли модель устройства одновременно и в команде, и в продукте, или придутся в основном на уровни, где модель устройства находилась и в команде, и в продукте, значит, наличие модели устройства одновременно в команде и в продукте на сдвиги сроков не влияет, и гипотеза ложна. Совпадение предсказания с результатом гипотезу не доказывает, поскольку уровни, где модели не оказалось одновременно в команде и в продукте, могут оказаться и самыми сложными, но расхождение предсказания с результатом гипотезу опровергает. Различение двух вариантов отсутствия инженерии от опровержения гипотезы не пострадает, поскольку оно следует не из наблюдений за миграциями, а из устройства облака. Опровергнуть само различение мог бы только провайдер, который открывает клиенту свою модель устройства настолько, что клиент может проверить её на собственных отказах.

Та же картина на уровень выше

У этой картины есть любопытное свойство: уровнем выше она повторяется в той же самой форме. Облачный провайдер относится к собственному продукту так же, как компания относилась к облаку. Компания пользовалась результатами инженерии провайдера, не видя целиком модели устройства, с помощью которой эти результаты предсказывались и обеспечивались, и обнаруживает отсутствие собственной инженерии только при миграции инфраструктуры из облака в on-premise. Провайдер опирается на инженерию собственной команды эксплуатации, но модель устройства, которую эта команда построила, остаётся в самой команде и в продукт, на основе которого провайдер строит своё облако, не попадает. Отсутствие этой модели в продукте обнаруживается только тогда, когда провайдер пытается эксплуатировать продукт в контуре заказчика (on-premise, а в предельном случае restricted site, куда у команды провайдера нет даже удалённого доступа). Попытка построить собственную платформу виртуализации вскрывает, есть ли у того, кто хочет стать её вендором, этот родственный дефект, то есть заложена ли модель устройства в сам продукт. За последние годы на рынке наблюдалось несколько хорошо финансируемых попыток создать такую платформу, и неудачные попытки распадаются на два класса, у которых следствие общее, а причины разные.

Первый класс составляют успешные облачные провайдеры, решившие продавать свою платформу для развёртывания в контуре заказчика (в форматах on-premise или restricted site). В облаке эта платформа вполне достаточна и проверена годами, поскольку её эксплуатирует сам провайдер силами большой команды эксплуатации, знающей каждую её деталь. У заказчика же та же платформа оказывается операционно неподъёмной: множество взаимозависимых сервисов, рассчитанных на то, что за ними круглосуточно смотрит масштабная и сильная команда, требуют от заказчика собственной команды, по размеру и компетенциям не уступающей команде большого облачного провайдера. Сложность такой платформы оправдана масштабом провайдера: значительная часть её сервисов существует ради тысяч клиентов (разделение ресурсов между ними, самообслуживание, квоты, учёт потребления), а стоимость эксплуатации почти не зависит от того, сколько клиентов работает на платформе. У провайдера эта стоимость распределяется на тысячи клиентов, а у заказчика операционная нагрузка целиком ложится на бюджет одной компании, которой к тому же приходится искать людей с компетенциями, сосредоточенными в основном у самих провайдеров и вендоров. Если масштаб заказчика несопоставим с масштабом провайдера, а для большинства заказчиков это именно так, содержание такой команды съедает ту самую экономию, ради которой затевалась миграция, поэтому такой команды у них нет и не будет. Модель устройства здесь существует, но живёт она в команде эксплуатации, без которой облако провайдера не может существовать, а не в самой платформе, и при выносе платформы за пределы облака модель остаётся у провайдера вместе с командой. Заказчик получает право “не знать”, закреплённое в договоре с вендором, но не возможность “не знать”.

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

Следствие в обоих случаях то же, что и у потребителя, только без смягчающего облачного слоя: модели устройства нет там, где она должна не просто быть, а уже работать. Любой инфраструктурный продукт, будь то платформа виртуализации, гиперконвергентная платформа или СХД, предоставляет своим клиентам право “не знать”, но возможностью “не знать” это право становится только тогда, когда в сам продукт заложена модель устройства. Такой продукт и есть инженерия для инженерии: заложенная в него инженерия вендора освобождает инженерию заказчика от знания внутреннего устройства продукта, но не от знания того, как продукт ведёт себя на своих границах, и та же форма повторяется ещё одним уровнем ниже. Модель, заложенная в продукт, отвечает на вопросы, которые иначе пришлось бы решать каждому клиенту самостоятельно: от того, что именно означает “записано” на каждом слое между гостевой операционной системой и носителем, до того, как поведёт себя кластер, у которого одновременно выйдут из строя диск на узле №3 и целиком узел №7 и пропадёт связь между площадками. Отказ в одной инсталляции касается одного заказчика, но ошибка в модели устройства, заложенной в продукт, проявится уже у нескольких или даже у каждого заказчика, у которого этот продукт установлен. Такую модель нельзя собрать из форм, поскольку культура передаёт то, как принято работать, а для построения такого продукта нужно понимание того, почему система ведёт себя именно так. Деньги, люди и процессы превращаются в такой продукт только там, где ими распоряжаются инженеры, практикующие инженерию как дисциплину, а не её культурную оболочку, и где модель устройства закладывается в сам продукт.

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

• команде без модели устройства инфраструктурных уровней (например, специалистам по доставке сервисов) поручили строить инфраструктуру с СХД и виртуализацией, в итоге инструменты пригодны для работы в режиме инженерии, но модели устройства нет в команде;

• команде с моделью устройства навязали продукт, не предназначенный для работы в режиме инженерии, в итоге модель устройства есть в команде, но пригодного для такой работы инструмента нет;

• команде без модели устройства инфраструктурных уровней поручили строить инфраструктуру на продукте, не предназначенном для работы в режиме инженерии, в итоге нет ни модели устройства в команде, ни пригодного инструмента.

Продуктом, не предназначенным для работы в режиме инженерии, здесь назван продукт, поведение которого команда не может заранее предсказать, проверить на стенде и объяснить по механизму, какой бы сильной ни была эта команда. Потребитель после миграции оказывается в первом или третьем варианте, если в его команде нет модели устройства инфраструктурных уровней. Заказчик платформы первого класса оказывается в первом варианте: продукт тот же, на котором провайдер годами работал в режиме инженерии, и для такой работы он пригоден, но модель своего внутреннего устройства в себе не несёт. Эта модель жила в команде провайдера и вместе с продуктом не переходит, поэтому держать её приходится команде заказчика, и чтобы её воспроизвести, эта команда должна быть сопоставима с провайдерской. Заказчик платформы второго класса оказывается во втором или третьем варианте. Облачный провайдер при этом подчиняется тому же следствию, что потребитель и интегратор: инженерия в его команде есть и годами проходила проверку реальными отказами в его собственной эксплуатации, за последствия которых он отвечал по SLA или описанию сервиса, но у заказчика конъюнкция собирается уже из другой команды, а в самом продукте модели устройства, которая заменила бы команду провайдера, нет. Закладывать модель в продукт провайдеру было, как правило, незачем: команда эксплуатации нужна ему в любом случае, и пока продукт работает только у него, модель в этой команде ничего не стоит сверх уже понесённых затрат. Работа по закладке модели в продукт, напротив, стоит денег, а видимого результата до выхода продукта к заказчику не даёт, поэтому рано или поздно попадает под нож экономии. Симуляция же возникает там, где отсутствие модели в команде или в инструменте прикрыто формами: инженерной культурой у потребителя, продуктовым нарративом у интегратора. Форма на всех уровнях одна и та же: это попытка обеспечить себе право “не знать” при отсутствии объективной возможности “не знать”. Потребитель предпринимает её, когда переносит облачную привычку в собственную инфраструктуру, заказчик платформы первого класса получает такое право по договору с вендором, а у интегратора его обещает слайд с единой платформой, подготовленный, разумеется, для стратсессии. И на каждом уровне за этой попыткой стоит стратегическое решение, принятие которого не заметили: потребитель, уходя в облако, сам того не заметив, решил, каких способностей у него не будет; провайдер, оставляя модель в команде эксплуатации, сам того не заметив, решил, что его продукт не сможет жить без этой команды; заказчик платформы первого класса, подписывая договор, сам того не заметив, решил зависеть от команды, которой у него нет; интегратор, сохраняя экономику проекта, сам того не заметив, решил остаться интегратором при любой вывеске.

Вместо вывода

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

Неприятный для некоторых вывод состоит в другом. В облаке право “не знать” совпадало с возможностью “не знать” на всех уровнях, отданных провайдеру, и таких уровней тем больше, чем дальше компания ушла от IaaS к PaaS и SaaS. В собственной инфраструктуре возможность “не знать” есть только в пределах внутреннего устройства продуктов, в которые вендор заложил модель, а всё остальное, включая то, как эти продукты собраны в систему, приходится знать команде, эксплуатирующей инфраструктуру. В тех частях инфраструктуры, где модель устройства не находится одновременно и в команде, и в продукте, остаётся лишь попытка сохранить право “не знать” при отсутствии объективной возможности “не знать”, и сохранность всех данных, проходящих через такую часть, зависит именно от неё, сколько бы инженерии ни было во всех остальных частях.

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