Базовая книга по инжинирингу платформ – новому подходу к управлению программными системами, при работе с которыми требуется обслуживать множество разных аппаратных архитектур и операционных систем. Показано развитие концепции DevOps и объяснено, как учитывать запросы и возможности пользователей независимо от способа работы с приложением, минимизировать задержки при обработке данных и упрощать масштабирование и поддержку многоплатформенных продуктов. Описан комплексный подход к управлению продуктом с учетом потребностей клиентов, разработчиков, системных администраторов и предприятия в целом, актуальный на любых программных платформах.
Для специалистов DevOps, системных администраторов, руководителей команд
Инжиниринг платформ — это командная игра. Перед вами правила игры.
Келси Хайтауэр, заслуженный инженер Google, соавтор книги «Kubernetes: Up & Running» (O’Reilly)
Техническое и управленческое руководство
В течение последней четверти века IT-организации постоянно борются с одной проблемой: как наладить управление кодом, инструментами и инфраструктурой, рассчитанными на совместную работу нескольких команд.
Централизованные команды инженеров часто не справляются с задачами и предлагают громоздкие системы, в которых игнорируются потребности пользователя, не обеспечивается должная стабильность и надежность. Некоторые организации ударялись в другую крайность, в результате пожиная хаос, так как небольшие команды тонули в огромном объеме задач.
Немногим удалось найти золотую середину, взяв на вооружение совершенно новый подход — инжиниринг платформ. С его помощью удается создавать надежные платформы, понятные пользователю, в значительной степени укрощать сложность, получать отдачу и повышать производительность труда в команде.
Это практическое руководство подробно рассказывает об инжиниринге платформ – новом направлении в индустрии DevOps — и помогает разработчикам, менеджерам и руководителям внедрить в организации те изменения, которые позволят развивать продукт как платформу. Вы узнаете, что входит и не входит в понятие «инжиниринг платформ» и почему эта парадигма становится необходимой.
Книга поможет:
- Привить в организации отношение к платформе как продукту и максимально реализовать на ней инженерный подход
- Понять, что входит и не входит в зону ответственности команд, занимающихся инжинирингом платформ
- Инициировать переход на инжиниринг платформ в рамках организации
- Узнать, как стать хорошим менеджером продукта в команде разработчиков платформы
- Научиться справляться с вызовами, возникающими при масштабировании платформ
- Взять на вооружение наилучшие практики, применяемые в успешных командах разработчиков платформ
Иэн Ноуленд — ветеран индустрии программного обеспечения с 25-летним стажем, занимавший пост старшего вице-президента в компании Datadog. С 2008 по 2016 год работал в компании AWS, где руководил проектами Amazon EMR и EC2 Nitro. В настоящее время является соучредителем стартапа.
Фурнье Камиль занимала должность руководителя в компаниях от зарождающихся стартапов до корпораций из рейтинга Fortune 50. Была в числе основателей Комитета по техническому надзору CNCF, в настоящее время входит в совет директоров журнала ACM Queue. Автор книги «The Manager’s Path» издательства O’Reilly.
Книгу “Инжиниринг платформ: техническое и управленческое руководство” можно купить в нашем интенет-магазине.
Отзывы на книгу “Инжиниринг платформ”. 13
Предисловие. 15
Введение. 17
От Камиль Фурнье. 17
Для кого предназначена эта книга. 18
Как читать эту книгу. 19
Онлайн-обучение O’Reilly. 20
Наши контакты.. 20
Благодарности. 21
От Камиль. 21
От Иэна. 21
От нас обоих. 22
ЧАСТЬ I. Что такое инжиниринг платформ и для чего он нужен. 23
Глава 1. Почему инжиниринг платформ приобретает такую важность. 25
Определение платформы и другие важные термины.. 26
Наше общее болото. 27
Как мы увязли в этом болоте. 30
Изменение № 1. Расширение возможностей выбора. 30
Изменение № 2. Более высокие операционные потребности. 33
Результат: вы тонете в болоте. 35
Как разработка платформ помогает выбраться из болота. 36
Ограничение использования примитивов при минимизации накладных расходов 36
Сокращение количества клея для каждого приложения. 37
Централизация затрат на миграцию.. 39
Предоставление разработчикам приложений возможности управлять тем,
что они разрабатывают. 40
Позвольте командам сосредоточиться на создании платформ.. 41
Резюме. 44
Глава 2. Основы инжиниринга платформ.. 45
Кураторский подход к продукту. 46
Разработка абстракций на основе программного обеспечения. 48
Основные абстракции: платформенный сервис и его API-интерфейсы.. 49
“Толстые” клиенты.. 50
Настройки OSS. 51
Интеграция реестров метаданных. 52
Обслуживание широкого круга разработчиков приложений. 54
Платформа в качестве фундамента. 56
Ответственность за всю платформу. 57
Поддержка платформы.. 58
Операционная дисциплина. 59
Резюме. 61
ЧАСТЬ II. Практика инжиниринга платформ.. 63
Глава 3. Как и когда начинать. 69
Содействие сотрудничеству при создании платформ на ранних стадиях. 69
Создание платформенных команд, которые заменят сотрудничество. 76
Соответствуют ли преимущества централизации владения понесенным затратам? 77
Осознайте, что коллективная динамика исчезла. 78
Сосредоточьтесь на решении проблем, а не на новых технологиях или архитектуре 79
Остерегайтесь новых инженеров, приходящих из гораздо более крупных компаний 80
Не спешите нанимать менеджеров по продуктам (и избегайте менеджеров проектов) 80
Дополнительные проблемы для платформ интеграции и совместного использования сервисов 81
Трансформация традиционной инфраструктуры организации. 84
Вся ваша инженерная культура должна измениться. 84
Определите наиболее перспективные направления в начале работы.. 85
Осознайте, что вы не можете просто нанять менеджеров по продуктам,
чтобы покончить с этим делом.. 86
Измените способ поддержки своих продуктов. 86
Обновите свой процесс собеседования. 86
Обновите свои системы признания и вознаграждения. 87
Не нужно нанимать слишком много менеджеров проектов. 87
Согласитесь с тем, что ваша команда будет тратить больше времени
на общение с клиентами и меньше — на написание кода. 88
Проведите необходимую реструктуризацию.. 88
И пусть это будет весело! 89
Резюме. 89
Глава 4. Создание отличных платформенных команд. 91
Риски, связанные с командами, работающими с платформами. 92
Слишком много внимания уделяется системам.. 92
Слишком много внимания уделяется разработке. 94
Различные роли платформенных инженеров. 95
Инженеры-программисты.. 96
Системные инженеры.. 98
Инженеры по надежности. 99
Специалисты по системам.. 100
Подбор и утверждение инженеров на все должности. 101
Разрешите специфические названия должностей. 103
Избегайте создания новой матрицы уровней инженеров-программистов. 103
Используйте, по возможности, одноуровневую матрицу для системных
ролей. 104
При необходимости создайте новый процесс собеседования при найме инженеров-программистов 105
Для разных системных ролей интервью не должно сильно меняться. 107
Интервью для выявления эмпатии к клиентам.. 108
Из кого получаются инженеры-менеджеры по разработке отличных
платформ?. 109
Опыт работы с платформами. 109
Опыт работы в крупных долгосрочных проектах. 110
Внимание к деталям.. 111
Другие роли в команде разработчиков платформы.. 111
Менеджеры по продуктам.. 111
Владельцы продуктов. 113
Менеджеры проектов / технические менеджеры программ.. 113
Девелопер-адвокаты, технические писатели и инженеры службы поддержки. 114
Формирование культуры команды разработчиков платформы.. 115
Разделение ответственности между командой разработчиков
и командой SRE. 115
Сильные и слабые стороны команды разработчиков. 115
Объединение команд и добавление управления продуктами. 116
Внедрение культуры разработки платформ.. 117
Резюме. 118
Глава 5. Платформа как продукт. 119
Культура продукта, ориентированная на потребителя. 120
Характеристики внутренних клиентов. 121
Взаимодействие с внутренними клиентами. 123
Эмпатия к клиентам.. 125
Как избежать ловушки магазина функций, чтобы обеспечить более широкое обслуживание клиентов 128
Поиск новых продуктов и анализ рынка. 130
Определение потенциальных платформенных продуктов. 131
Развитие существующих предложений: сглаживание граней или переосмысление проблемы 134
Маркетинговые исследования: обоснование новых инвестиций. 136
Метрики продукта. 141
Успешная реализация продукта: составление дорожной карты.. 146
Видение. Долгосрочное. 147
Стратегия. Среднесрочная перспектива. 147
Цели и метрики. Планы на год. 148
Контрольные точки. Ежеквартально. 148
Спецификация функций. 149
Практика делает всё более совершенным.. 149
Типы сбоев в разработке продукта. 151
Недооценка стоимости миграции. 152
Завышение бюджета на изменения в работе пользователей. 152
Переоценка новых функций при низкой стабильности. 153
Слишком много менеджеров по продуктам для инженерной команды.. 154
Ситуация, когда менеджеры по продуктам выполняют работу,
которую должен делать инженерный менеджмент. 154
Резюме. 155
Глава 6. Эксплуатация платформ.. 157
Практика работы по вызову. 158
Почему важно обслуживание по вызову в режиме 24´7. 159
Зачем объединять DevOps?. 159
Переход к устойчивой нагрузке по вызовам.. 161
Методы поддержки. 164
Почему инженеры-разработчики платформы должны выполнять работу
по поддержке. 165
Этап 1. Формализуйте уровни поддержки. 166
Этап 2. Отделите некритическую поддержку от поддержки по вызову. 168
Этап 3. Наймите специалиста по поддержке. 169
Этап 4. Масштабирование с помощью организации технической
поддержки. 171
Практика оперативной обратной связи. 173
SLO и SLA необходимы. Бюджеты ошибок не обязательны.. 174
Управление изменениями. 176
Синтетический мониторинг. 178
Операционные обзоры.. 180
Резюме. 182
Глава 7. Планирование и поставка. 183
Планирование долгосрочных проектов. 184
Уточнение целей и требований в документе-предложении. 184
Переход от предложения к плану действий. 186
Не затягивайте работу. 188
Планирование дорожной карты “снизу вверх”. 192
Работа по принципу “Не выключай свет” (KTLO) 193
Приказы.. 194
Усовершенствования системы.. 195
Повышение эффективности и производительности. 197
Повышение безопасности и соответствия требованиям.. 199
Сводим всё это воедино. 200
Сообщайте о победах и трудностях раз в две недели. 204
Основы.. 205
Зачем? В чем ценность?. 205
Что? Cтруктурирование побед и трудностей. 206
Не забывайте о проблемах! 207
Научите свою команду писать о победах и трудностях. 208
Резюме. 210
Глава 8. Реорганизация платформ.. 213
Почему преобразование архитектуры предпочтительнее, чем создание
версии 2. 214
Разное инженерное мышление. 216
Архитектура определяет требования к типу мышления. 217
Почему сложно создавать платформы версии 2 и предпочтительнее
перестроить архитектуру. 219
Решение проблем безопасности с помощью архитектуры.. 222
Ограничения реорганизации архитектуры.. 228
Совместимость. 228
Тестирование. 228
Более низкие требования к средам.. 229
Транши, медленное внедрение и отставание в версии. 230
Планирование реорганизации архитектуры.. 230
Шаг 1. Масштабно продумайте конечные цели реорганизации
архитектуры.. 232
Шаг 2. Учитывайте затраты на миграцию.. 235
Шаг 3. Определите основные достижения за следующие 12 месяцев. 236
Шаг 4. Заручитесь поддержкой руководства и будьте готовы ждать. 237
Резюме. 238
Глава 9. Миграция и закат платформ.. 241
Антипаттерны миграции. 242
Инженерия упрощенной миграции. 243
Используйте абстракции продукта, которые сводят к минимуму
количество “клея” и ограничивают вариативность. 244
Создавайте архитектуру, предусматривающую прозрачную миграцию.. 245
Отслеживание метаданных об использовании. 247
Разрабатывайте автоматизацию, чтобы избежать использования
буферов обмена. 249
Документооборот для плавной миграции. 250
Координация плавных миграций. 252
Масштабируйте, ограничивайте и определяйте приоритетность запланированных изменений 252
Предоставляйте информацию заблаговременно и публично. 254
Пройдите последние 20 % пути. 255
Продуманное использование приказов. 256
Закат платформ.. 258
Принятие решения о прекращении использования (закате) платформы.. 258
Координация заката. 261
Не бойтесь сворачивать работу, когда в этом есть смысл. 262
Резюме. 262
Глава 10. Управление взаимоотношениями с заинтересованными сторонами 265
Составление карты заинтересованных сторон: матрица “власть-интерес”. 267
Общение с надлежащей прозрачностью.. 271
Остерегайтесь чрезмерного распространения деталей. 271
Разумно используйте регулярное общение в формате 1:1. 273
Следите за ожиданиями и обязательствами. 274
Расширяйте масштаб с помощью совместных совещаний и консультативных советов по работе с клиентами 275
Увеличивайте объем коммуникации в сложных ситуациях. 275
Поиск приемлемых компромиссов. 276
Четко представляйте последствия для бизнеса. 277
Иногда говорите “Да, но с компромиссами”. 278
Говорите “Нет”, не разрушая отношений. 279
Компромисс на теневых платформах. 282
Финансовые проблемы: управление затратами и бюджетом.. 285
Шаг 1. Определите, кто получит выгоду завтра. 286
Шаг 2. Распределите работу по группам (но не поручайте отдельным исполнителям) 287
Шаг 3. Предложите, что сократить, и выскажите твердое мнение о том,
что оставить. 288
Резюме. 289
ЧАСТЬ III. Как выглядит успех?. 291
Глава 11. Ваши платформы согласованы.. 293
Соответствие цели. 295
Приведение команд в соответствие с поставленной целью с помощью правильного подбора сотрудников 296
Приведение культуры в соответствие с целями и общепринятыми
методами работы.. 297
Приведение культуры в соответствие с целями при помощи
сотрудничества команд. 297
Согласование стратегии продукта. 298
Развивайте кросс-платформенное мышление с помощью независимого управления продуктами 298
Поддерживайте кросс-платформенную архитектуру с помощью независимых индивидуальных контрибьюторов. 299
Ищите обратную связь в комментариях к опросам клиентов платформы.. 300
Разумно устраняйте несогласованность с помощью реструктуризации. 301
Согласование планов. 302
Согласовывайте только крупные проекты, а не каждую деталь. 302
Будьте честны в борьбе с несогласованностью.. 303
Окончательное согласование зависит от принципиального лидерства. 304
Объединение усилий: приведение организации к согласованию.. 304
Резюме. 307
Глава 12. Вашим платформам доверяют. 309
Доверие к стилю вашей работы.. 311
Укрепляйте доверие, расширяя возможности опытных руководителей. 312
Оптимизируйте рост доверия, упорядочивая варианты использования. 313
Верьте в свои крупные инвестиции. 314
Заручитесь поддержкой технических заинтересованных сторон,
чтобы получить доверие к перестройке архитектуры.. 315
Для завоевания доверия к новым продуктам ищите спонсорскую
поддержку со стороны руководства. 315
Поддерживайте старые системы, чтобы сохранить доверие. 316
Завоевание доверия требует гибкости в отношении того, что является “правильным” 316
Доверие для определения приоритетности поставки. 317
Создайте культуру скорости поставки. 318
Расставляйте приоритеты в проектах, чтобы высвободить потенциал команды 319
Оспаривайте предположения о сфере применения продукта. 320
Объединяем всё воедино: случай с перегруженной платформой. 322
Резюме. 324
Глава 13. Ваши платформы справляются со сложностями. 327
Управление случайной сложностью, связанной с координацией
действий людей. 330
Управление сложностью, связанной с теневыми платформами. 332
Управление сложностями, возникающими при неконтролируемом росте. 335
Управление сложностью с помощью поиска нового продукта. 337
Объединение усилий: баланс между внутренней и внешней сложностями. 338
Неудачи при использовании OSS. 339
Безуспешная попытка изменить правила игры.. 339
Теневые платформы вынуждают к перезагрузке. 340
Запуск после перезагрузки. 341
Резюме. 342
Глава 14. Ваши платформы любят. 343
Любовь работает. 346
Любовь может выглядеть как хитрость. 347
Любовь может быть очевидной. 349
Соединяем всё вместе: любовь делает ваших пользователей классными. 350
В заключение. Что такое любовь? Детка, не делай мне больно. 352
Заключительные замечания. 353
Предметный указатель. 357
Об авторах. 366
Об изображении на обложке. 367
