Парадокс SLA-Engineering

Почему проекты, ориентированные на результат, как правило, стимулируют больше инноваций, чем проекты, основанные на рецептах

Вначале программной инженерии не было. Но по мере того, как команды распределялись по миру, им нужно было сообщить, чего они хотят друг от друга и как они этого хотят.

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

Но в небольшом уголке отрасли группа людей, занимающихся утилитарными продуктами, создавала вещи, которые теперь должны были работать: они знали, чего от них хотят, и знали, сколько они готовы за них заплатить. Они создали подход, ориентированный на результат. Этот подход был прост: они просили, что хотели, и проверяли, получили ли они то, что просили. Эти результаты были названы SLA (соглашения об уровне обслуживания) или SLO (цели уровня обслуживания). В этом посте я буду называть их SLA.

Более крупная отрасль решила, что хочет быть идеальной. Он хотел создавать лучшее, а не достаточно хорошее. Поскольку нельзя было доверять простым людям в выборе лучшего, это спроектировало бы лучшее, а простолюдинам оставалось только выполнять. Он продвигал подход, основанный на рецептах. Если бы рецепт был идеально разработан, идеально выражен и идеально реализован, результат по определению был бы наилучшим из возможных.

В отрасли будут архитекторы, создающие идеальные рецепты, и повара, которые будут их выполнять. Все, что нужно было создать отрасли, - это инструменты, чтобы помочь этим поварам. Это привело к Rational Rose, UML, SOAP, CORBA, XML-DTD и, в некоторой степени, к SQL, но, что еще хуже, к Transactional-SQL, хранимым процедурам и так далее.

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

(Я слышу, вы самодовольные ребята, занимающиеся функциональным программированием. Прекратите.)

Сегодня я хочу исследовать причины этого парадокса. Но сначала ... давайте интуитивно поймем, откуда взялись эти два лагеря.

Интуитивно понятный процесс, позволяющий получить самое лучшее

Если вы хотите спроектировать / спроектировать самую совершенную систему в мире, имеет смысл начать с жадного алгоритма. На каждом этапе жадный алгоритм выбирает самые лучшие технологии, методологию и реализацию, которые может предложить мир. Вы проверяете это до конца. Убедившись, что вы не смогли выбрать лучший компонент, вы его используете. Любой повар скажет вам, что качественный ингредиент, приготовленный с нежной приправой, затмит посредственный ингредиент, скрытый пряностями.

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

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

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

Следуя этому рецепту, вы теперь получаете абсолютно ультрасовременное решение. Никто не может сделать лучше. По словам Джона Хаммонда, не жалел денег.

Разработка на основе SLA должна упускать возможности

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

Затем система проектируется на основе предположения о поведении компонентов. Если система встает, компоненты строятся индивидуально, чтобы соответствовать хорошо понятному поведению.

Просто глядя на SLA, можно определить, можно ли вообще построить компонент. Как домашний повар, вы все пробуете во время приготовления, и все правильно. Если общий SLA составляет 0,2% соли, а вы используете 0,1%, на следующем шаге вы добавляете 0,1% соли.

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

Это утилитарная индустриальная система. Похоже, что нет никакого эстетического смысла, искусства или даже попытки сделать что-то лучше. Нет стремления превзойти.

При проектировании на основе SLA следует упускать из виду все самое лучшее в мире.

Что мы ожидали

Ожидание здесь было для всех очевидным.

Если бы вы сказали кому-то создать вам веб-сайт, который будет работать за 20 мс, они сделают меньше всего, чтобы это произошло.

Если бы вместо этого вы дали им идеальный рецепт, вы могли бы получить 5 мс. Даже если вы получили 25 или 30 мс, они точно следовали вашему рецепту, вы просто достигли теоретического совершенства.

Рецепт более нормализован; он компактен. Как только мы зафиксируем, что это будет SQL-сервер с защитой паролем, группами безопасности, ролями, участниками, группами пользователей, процессами подключения и отключения, все остальное будет следовать.

С другой стороны, SLA-люди, вероятно, платят больше и получают меньше, и, что еще хуже, они даже не знают, на сколько. Хуже того, они также определяют ненормализованные SLA. Если они что-то не упоминают, они этого не понимают. Может ли повар добавлять или удалять произвольные ингредиенты, помимо соли? О ужас!

Парадокс

Как это ни парадоксально, мы наблюдали полную противоположность.

Разработка на основе SLA дала нам Actor Models, NoSQL, BigTable, Map-Reduce, AJAX (так назывались «веб-приложения» всего десять лет назад), Mechanical Turk, параллелизм и, совсем недавно, Blockchain. Наука и технологии, которые были революционными, революционными, элегантными, простыми, удобными и широко применимыми.

С другой стороны, разработка, основанная на рецептах, продолжала обременять нас UML, CORBA, SOAP, XML DTD, тенью ООП Алана Кея, Spring, XAML, симметричной многопроцессорной обработки (SMP), параллелизма и т. Д. Еще большая нагрузка. Больше ограничений. Больше API. Больше тюрем.

Всего десять лет назад «приложение в вашем браузере» привело бы к Java-апплетам, Flash, Silverlight или другому подобному «собственному плагину». Улучшение ECMAScript, чтобы сделать его более быстрым, не было бы результатом, основанным на рецептах.

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

Это похоже на социальную догму: когда рецепты не дают наилучших результатов, у нас возникают две инстинктивные реакции. Первый - отказаться от SLA-решения путем некоторой тривиализации. Второй - удвоить ставку и убедить себя, что мы недостаточно требовали. Нам нужно требовать БОЛЬШЕ рецептов, больше строгости, больше совершенства.

Понимание парадокса

Попробуем разобраться в парадоксе. Это очевидно, если мы потратим время на то, чтобы понять контекст и обстоятельства в социальной обстановке, где человек - это человек с амбициями, эмоциями, творческими способностями и энергией, а не с идеалом установка, где «человек» - это бесстрастный и амбициозный дрон, который заполняет код в поле UML.

SLA контекстуализируют вашу проблему

Это очевидный простой. Если вы разрабатываете веб-поиск без SLA, вы получите сложный распределенный SQL-сервер со всевозможными каркасами, обеспечивающими его работу под нагрузкой. Если вы сначала посмотрите на SLA, вы придете к совершенно новой идее: это пары ключ-значение. Зачем мне нужны деревья B + и сложные файловые системы?

Точно так же, если бы вы спросили: Какая система лучше всего для параллельной генерации индексов?, Современными в то время были PVM / MPI. Наличие подключаемых операций Map / Reduce считалось настолько крутым, что каждое резюме в середине 2000-х годов должно было упоминать эти функции (что-то настолько обычное и тривиальное сегодня, ваш javascript kiddie веб-разработчик использует его для обработки потоков). запуск миллиона дешевых машин не было ни лучшим, ни современным. :-) Никакого рецепта к этому не пришло бы.

SLA контекстуализируют то, что НЕ является проблемой

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

Опять же, наличие соглашений об уровне обслуживания помогло Google сосредоточиться на том, что НЕ является проблемой. Что НЕ является целью. Что НЕ является целью. Это важнее, чем вы думаете. Возможность игнорировать ненужный багаж - мощный инструмент.

Вам нужны эти фабрики? Вам это нужно, чтобы быть синглтоном? Это должно быть глобальным? SLA борются с чрезмерной инженерией.

SLA поощряют системные решения

Какие? Звучит безумно! Тем не менее это правда.

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

С другой стороны, разработка, основанная на рецептах, не привязанная к результату, продолжала идти сложным путем. Решение проблемы переполнения буфера заключалось в большем статическом анализе, большем сканировании, большем количестве предупреждений компилятора, большем количестве ошибок, большем количестве стажеров, большем количестве проверок кода. Его решение проблемы зависимости заключалось в большем количестве манифестов зависимостей на основе XML и всего багажа семантического управления версиями. Его решением для портативных приложений было больше виртуальных машин, но еще один стандарт, больше плагинов и т. Д.

Без SLA Polyverse не существовала бы

Насколько я верю в разработку на основе SLA? Есть ли у меня доказательства того, что подход, основанный на том, чтобы сначала поставить цель, а потом работать в обратном направлении, работает? Поливерс - живое доказательство.

Когда мы увидели взлом Premera и если бы мы задались вопросом, что является САМЫМ ЛУЧШИМ в мире, мы подумали бы о БОЛЬШЕМ сканировании, БОЛЬШЕМ обнаружении, БОЛЬШЕМ ИИ и БОЛЬШЕМ нейронных сетях, и, возможно, БОЛЬШЕМ блокчейне. Втисни столько, сколько сможем.

Но когда мы спросили себя: «Если SLA не означает потерю более десяти записей в год или крах», мы пришли к совершенно другому системному выводу.

Когда случился Equifax, если бы мы спросили себя, каково состояние дел, мы бы сделали БОЛЬШЕ проверок кода, БОЛЬШЕ исправлений, БЫСТРЕЕ исправлений и т. Д.

Вместо этого мы спросили: Что должно произойти, чтобы атака стала невозможной? Мы придумали Полискриптинг.

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

Google доказал это. Facebook это доказал. Apple доказала это. Microsoft доказала это. Все они верят в это. Определите цели. Сосредоточьтесь на них. Игнорируйте все остальное. Изменить мир.