Сдвиг влево и безмасштабный прочный манифест

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

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

Это перепев идей антихрупкости Талеба, resilience в классической системной инженерии, только по линии защиты/security (и даже не безопасности, что "моя система никого не убьёт в своём окружении").
Переписываем в таком же стиле тамошний FAQ:

"Прочный" описывает организацию, создающую системы, у которой культура быстрого развития её возможностей создавать доступные, выживаемые/survivable, обороняемые/defensible, защищённые/secure и устойчивые к разрушениям системы. Прочные системы используют конкуренцию, кооперацию и эксперименты, чтобы учиться и улучшать, нежели делать одни и те же ошибки снова и снова. Прочные организации активно ищут угрозы и создают оборону от них до того, как эти угрозы станут проблемой. "Прочное" может также быть использовано для описания систем, создаваемых прочными организациями. Эти системы не только хорошо защищены против атак, но также способны анализировать себя, докладывая статус собственной защиты, обнаруживая атаки в их ходе, а также способны отвечать как надо. "Прочный" -- это не технология, способ разработки, модель жизненного цикла или организационная структура. Это даже не существительное. "Прочный" -- это не то же самое, что "защищённый". "Защищённый" -- это состояние дел в определённый момент времени. Но "прочный" описывает постоянное опережение угроз по ходу времени. Прочные организации создают защищённый код как побочный продукт их культуры. Ты прочный, поскольку ты принял вызов, оборудуешь твою организацию и твои системы, постоянно экспериментируешь, чтобы узнать, не поломается ли что, и выживаешь в процессе закалки себя опытом реального мира. Прочные организации создают прочные системы, спроектированные для противостояния не только сегодняшним угрозам, но также и будущим проблемам.

Ну, и как этого достичь? Сдвигом влево/shift left -- сдвигом работ по защитам влево по V-диаграмме, https://devopedia.org/shift-left. Началось с test shift left (TDD), а затем пошло safety shift left и security shift left. Всё это противостояло разным документам из регуляторных органов, которые safety и security review предусматривали после окончания создания, но до эксплуатации. Типа "вы тут делайте, а потом мы изучим и дадим рекомендации". Нет, делать приходится всё время (нет момента "сделали"), плюс учитывать эти concerns нужно с самого начала, наравне с архитектурными и domain-функциональными.

Кстати, очень просто разделять safety и security: по границе системы. Если угрозы из окружения, то это security, а если угрозы от тебя в окружение -- это safety. Разработчик посудной лавки воспринимает слона как окружение, для него противослоновые меры -- это security. Для разработчика слона меры предосторожности, чтобы чего не побить в посудной лавке -- safety. Если в окружении автомобиля находятся люди (включая тех, кто внутри салона -- они будут от собственно автомобиля "снаружи"), то автомобиль их не должен покалечить, это safety. Если злые люди калечат автомобиль (из салона, или снаружи), то security. Разница при этом в том, что security предполагается, что делается против умных и настойчивых агентов (слон в посудную лавку попадает не случайно, а буквально прорывается, а потом намерен порушить всё, до чего дотянется, а люди царапают автомобиль со злобной ухмылкой, намеренно -- никакой презумпции невиновности). Safety ровно наоборот: "извините, мы не хотели, так получилось, не подумавши". Всякие антихрупкости и resilience всплывают, когда "агентом" является что-то менее злонамеренное, которое не планирует тебя повредить, но уж так получилось, звинити. Слон сбежал и зашёл в посудную лавку, это по линии resilience. Всё одно лечить надо через shift left, обсуждать такое рано по жизненному циклу, а жизненный цикл у нас становится вечный (continuous development, continuous delivery), поэтому обсуждать надо вечно рано.

Ещё интересно, что всё это постоянно болтается на границе архитектуры и разработки -- и вроде как должно быть внутри них, но тем не менее, оказывается всё время снаружи:
-- ещё Дональд Файерсмит (совершенно замечательный человек, он приезжал к нам в русское отделение INCOSE, https://en.wikipedia.org/wiki/Donald_Firesmithhttp://donaldfiresmith.com/about-me/) говорил, что всякие защитники-безопасники это системные инженеры, ибо они про "всю систему в целом" (сегодня после подробного обсуждения в части архитектуры в связи с обратным манёвом конвея и loosely coupling systems мы понимаем, что это роль в отношении governance для всех команд -- выставляет ограничения и менторит. Архитектура про это самое loosely coupling и антихрупкость, а вот safety и security что-то другое: у "силовиков" другие вузы, другие конференции, другие журналы, другой язык, другое всё, и непонятно, случайно ли это). Вообще, нет таких системных инженеров, которые бы не говорили, что "нужно увеличить внимание к безопасности и защите" (но они говорят, но не всегда делают -- ибо этим всем заниматься можно вечно, зато небезопасный сервис хоть что-то сделает, а полностью безопасный будет изолирован от мира, поэтому ничего не сделает, и может вообще не существовать).
-- John Doyle призывает заботиться об интерфейсах в части безопасности, и говорит об эволюционности (https://ailev.livejournal.com/1622346.html): на интерфейсы садятся паразиты, это эволюционно неизбежно. И он же говорит, что на иммунную систему нужно находить управу, ибо "слишком прочный" -- это ни разу не рабочий, закованная в броню лошадь скакать не может, и даже идти вряд ли может, но зато она защищена и безопасна (если не стоять под ней в тот момент, когда она подо всей этой защитой рухнет). И что "аутоиммунные заболевания" ("Полицейское государство" это просто аутоиммунное заболевание) -- это неизбежная плата за защиту. И что паразиты всё одно будут, но какие-то из них станут потом симбионтами. John Doyle поминает математику U-образных кривых и замечает, что эта математика многоуровнева, то есть все эти соображения верны для многих вложенных систем, на всех интерфейсах. Так что математику можно брать, например, у John Doyle с его учениками.
-- соображения из опыта микросервисов. В https://gist.github.com/jezhumble/a8b3cbb4ea20139582fa8ffc9d791fb2 (текст аж 2011 года) говорится о микросервисной архитектуре на её заре: там всё в крупной организации (Amazon) было так плохо, что интерфейсы сервисов внутри организации пришлось серьёзно защищать (никакого доверия к огромному числу внутренних команд), поэтому практически не было проблем потом при публикации их наружу, они были уже прочными.
-- куча этических вопросов: ваша система по линии safety засекла злоумышленника (потенциального!) и надёжно его унасекомила (устранила, так сказать, причину -- вплоть до "нет человека -- нет проблемы" Агент-система, который начинает планировать, а это когда AI внутри, что неизбежно, уже не только убегает или кусается, он устраняет саму возможную причину угрозы). К такой системе и ещё хозяевам, понятно, дальше вопросы по safety со стороны злоумышленника (он мог быть не злоумышленником, а "не знал, прастити". Или "вы превысили уровень необходимой самозащиты, ответ ваш чрезмерный"). И это только самое начало разговора, потому как у нас же много систем, много системных уровней и везде конфликты-конфликты-конфликты. Поэтому "слишком прочная" система оказывается лекарством, которое хуже болезни.