10.4 Поддержка больших и долгоживущих систем

Обзор и мотивация

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

Почему это важнее для больших организаций? Непрерывность обязательств. Стартап может переписать или бросить своё программное обеспечение. Национальное правительство не может перестать платить пенсии, пока проводит рефакторинг. Корпорации и ведомства владеют системами, чей отказ имеет последствия, измеряемые средствами к существованию, безопасностью или общественным доверием. И они владеют многими из них разом, обслуживаемыми людьми, приходящими и уходящими десятилетиями. Центральные угрозы не экзотичны. Это медленная эрозия людей, понимающих систему (фактор автобуса, то, как мало людей должно уйти, прежде чем знание о системе будет потеряно), накопление недокументированного знания в нескольких головах, распад технологического стека в сторону конца срока службы и паралич, наступающий, когда система становится слишком критичной, чтобы её трогать, и слишком плохо понятной, чтобы безопасно менять.

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

Ключевые принципы

• Каждой критичной системе всегда нужен владелец. Владение это непрерывное назначение, а не память о том, кто её написал.
• Знание, живущее в одной голове, риск, а не актив. Институционализируйте понимание до ухода человека.
• Скучно это функция. Для долгоживущих критичных систем стабильность и предсказуемость нередко важнее новизны.
• Планируйте конец в начале. Каждая система будет выведена или заменена; проектируйте и документируйте на этот день.
• Изменение то, как вы остаётесь в безопасности. Система, слишком страшная для прикосновения, уже отказывает; способность меняться черта выживания.
• Непрерывность переживает отдельных людей. Проектируйте команды, документацию и процессы так, чтобы ни один уход не был кризисом.
• Доверие настоящий продукт. Для систем, обращённых к гражданам и клиентам, надёжность и справедливость, поддерживаемые во времени, и есть миссия.

Рекомендации

Установите стюардство и непрерывность владения

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

Снижайте фактор автобуса и риск ключевого человека

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

Институционализируйте передачу знаний

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

Управляйте устареванием, закатом и концом срока службы

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

Поддерживайте системы десятилетиями

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

Балансируйте инновации со стабильностью и доверием

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Сохранять и сопровождать старую систему	Сохраняет институциональное знание; малое разрушение; проверенная надёжность	Стареющий стек; дефицитные навыки; растущий риск при отсутствии сопровождения
Переписывание «всё разом»	Свежий стек; сбрасывает накопленный хлам	Очень высокая доля провалов; теряет с трудом добытое знание крайних случаев
Инкрементальная модернизация	Непрерывное снижение риска; продолжает работать	Медленно; требует устойчивого финансирования и дисциплины
Передача с упором на документацию	Явная, доступная для поиска запись	Распадается без сопровождения; пропускает неявное знание
Передача через людей (парное программирование/ротация)	Долговечное рабочее знание; устойчивые команды	Стоит нынешней продуктивности; нужно намеренное планирование
Заморозка критичного ядра	Максимальная стабильность в краткосрочной перспективе	Стек стареет до несопровождаемости; становится слишком страшным для прикосновения

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

Вопросы для обсуждения с командой

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

2. Когда вы заменяете систему, кто подотчётен за то, чтобы действительно выключить старую? Вечный параллельный запуск распространённый и дорогой отказ: старая и новая системы работают бок о бок бесконечно, потому что никто не владеет отключением, оставляя вас сопровождающим две системы и получающим безопасность ни одной. Воспринимайте каждый закат как управляемый проект с названной подотчётностью за завершение вывода из эксплуатации, картированным списком потребителей, путём миграции и реалистичным сроком. Принесите свидетельства: сколько «временных» параллельных запусков или полувыведенных систем всё ещё тянут сопровождение в вашем хозяйстве сегодня? Сохраняйте данные и записи для соблюдения юридических правил хранения долго после остановки системы, но не позволяйте хранению стать оправданием никогда не закончить. Плохо сделанный закат оставляет системы-зомби, не сопровождаемые, но всё ещё используемые, худшее из всех миров.

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

4. Когда вы в последний раз меняли вашу самую критичную долгоживущую систему и осмеливается ли кто-нибудь ещё? Система, которой никто не касался год, не стабильна, а дрейфует в ловушку «слишком страшно трогать», где каждое изменение внушает страх, и потому стек тихо выходит из поддержки. Для большой организации это важно, потому что паралич накапливается: чем дольше заморозка, тем больше знание блекнет и тем рискованнее становится неизбежное изменение. Принесите свидетельства: для каждой критичной системы дату последнего намеренного изменения, размер наименьшего изменения, которое кто-либо осмелился бы предпринять сегодня, и можно ли рутинный патч зависимости или безопасности отгрузить на этой неделе без героизма. Конкурирующее соображение реально, потому что изменение тоже вносит риск, поэтому цель не суета, а устойчивый ритм малых обратимых хорошо протестированных шагов. В корпоративных и государственных хозяйствах, где замороженное ядро может сидеть под сервисом для граждан десятилетие, воспринимайте «мы никогда не меняем это» как красный флаг, а не заверение, и финансируйте непрерывное сопровождение, сохраняющее возможность меняться.

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

6. Где в вашем хозяйстве стабильность ценность, а новизна обязательство, и как вы держите эту границу честной? Не каждая система вознаграждает одно и то же обращение: основные системы, от которых граждане и клиенты зависят ежедневно, обычно вознаграждают надёжность и осторожное изменение, тогда как края вознаграждают эксперименты, и путаница двух тратит деньги впустую или приглашает сбои. Для большой организации риск в том, что амбиции и карьерные стимулы толкают захватывающие переписывания именно в долговечное ядро, которое должно оставаться скучным. Принесите свидетельства: карту вашего хозяйства, отмечающую, где надёжность миссия, а где новизна создаёт ценность, плюс недавние изменения, пересёкшие эту линию в любую сторону, и чего они стоили. Конкурирующее соображение в том, что даже стабильное ядро должно эволюционировать, поэтому «стабильное» не может стать оправданием заморозки. В корпоративных и государственных контекстах привяжите эту границу к явным ярусам критичности и названному органу, который может наложить вето на рискованное переписывание системы, чей отказ общество не может позволить себе увидеть, чтобы суждение не дрейфовало с тем, кто громче в этом квартале.

Взгляд по секторам

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

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

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

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

Примеры

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

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

• Героический сопровождающий. Один незаменимый человек, понимающий систему; его уход экзистенциальное событие.
• Заморозь и забудь. Объявление критичной системы «готовой», прекращение сопровождения и наблюдение за тем, как её стек стареет до несопровождаемости.
• Обречённое переписывание. Ставка организации на замену целиком, отбрасывающую закодированное знание и обычно превышающую сроки или проваливающуюся.
• Осиротевшие системы. Критичное программное обеспечение без текущего владельца, замечаемое только когда ломается.
• Театр документации. Тома документов, устаревших, неотработанных и которым никто не доверяет.
• Вечный параллельный запуск. Старая и новая системы работают бок о бок бесконечно, потому что никто не подотчётен за отключение.
• Потеря неявного знания. Допуск ухода экспертов без перекрытия, так что чувство системы испаряется.
• Слишком страшно трогать. Система настолько плохо понята, что любое изменение внушает страх, что гарантирует её распад.

Модель зрелости

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

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

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

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

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

Идеи для обсуждения

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

Главные выводы

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

Источники и дополнительное чтение

• Michael Feathers, Working Effectively with Legacy Code
• Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
• Frederick P. Brooks Jr., The Mythical Man-Month
• Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
• Sam Newman, Monolith to Microservices
• Martin Fowler, Refactoring and writings on the Strangler Fig pattern
• Betsy Beyer et al., Site Reliability Engineering and The Site Reliability Workbook (Google)
• Diomidis Spinellis, Code Reading: The Open Source Perspective
• U.S. Government Accountability Office, reports on federal legacy IT modernisation