Вы находитесь на странице: 1из 1106

ББК 32.973.26-018.2.

75
/158
удк 681.3.07

Компьютерное издательство "Диалектика"


По общим вопросам обра щайтесь в издательство "Диалектика" по адресу:
info@dialektika.com, http://www.dialektika.com

/lимончелли, Томас А., Хоrан, Крисrина Дж., Чейлап, Страта Р.


/158 Практика системного и сетевого администрирования, том 1, 3-е иц. : Пер.
с англ. - СпБ.: ООО "Альфа-книга", 2018. - 1 104 с.: ил. - Парал. тит. англ.
ISBN 978-5-6040043-1-9 (рус.)

ББК 32.973.26-018.2.75
Все названия программных продуктов являются зареrистрированными торговыми марками
соответсrвующих фирм.
Никакая часть настоящею изданш1 ни в каких целях не может быть воспроизведена в какой
бы то ни было �юрме и какими бы то ни было средсrвами, будь то электронные или механиче­
ские, включаJI фотокопирование и запись на магнитный носитель, если на это нет письменного
разрешения издател1.сrва Addison-Wesley PuЫishiпg Company, !пс.
Authorized translation from the Englisl1 language edition puЫished Ьу Addison-Wesley
PuЬlishing Company, lnc., Copyright © 2017 Thomas А. Limoncelli, Christina J. Lear nee Hogan,
Virtual.NET lnc., Lumeta Corporation.
АН rights reserved. No part of this puЫication may Ье reproduced, stored in а retrieval system, or
transmitted, in any form, or Ьу any means, electronic, mechanical, photocopying, recording, or other­
wise, without the prior written permission of PuЬlisher.
Russian language edition puЬlished Ьу Dialektika-Williams PuЫishing House according to the
Agreement with J{&J Enterprises lnternational, Copyright © 2018
Excerpt: "Noёl," Season 2 Episode 10. The West Wing. Directed Ьу Thomas Schlamme. Teleplay
Ьу Aaron Sorki11. Story Ьу Peter Parnell. Scene performed Ьу John Spencer and Bradley W hitford.
Original broadcast December 20, 2000. Wamer Brothers Burbank Studios, Burbank, СА. Aaron Sorkin,
John Wells l'roduction, Warner Brothers Television, NBC © 2000 Broadcast television.
Chapter 26 photos © 2017 Christina J. Lear nee Hogan.

Научно-популярное u.JiJaнue
Томас А. Лимончелли, Кристина Дж. Хоrан, Страта Р. Чейлап
Практика системного и сетевого администрирования
То м 1, 3-е издание

Подшкано в 11ечать 20.04.2018. Формат 70х100/16


Гарнитура Times
Усл. печ. л. 69,0. Уч.-изд. л. 78,4
Тираж 400 экз. Заказ № 3376

Ошечатано в АО "Первая Образцовая п11101рафю1"


Филиал "Чеховский Печаn1ый Двор"
142300, Московская область, r. Чехов, ул. Поли�рафис1·ов, л. 1
Сайт: www.chpd.ru, E-mail: sales@chpd.ru, тел. 8 (499) 270-73-59

ООО"Альфа-книrа", 195027, Санкт-Петербург, Мапштоюрская ул., д. 30, лит А, пом. 848


ISBN 978-5-6040043-1-9 (рус.) © 2018 Компьютерное издательсrво "Диалектика",
перевод, оформление, макетирование
ISBN 978-0-321-91916-8 (англ.) © 2017 Thomas А. Limoncelli, Christina J.
Lear nee Hogan, Virtual.NET lnc., Lumeta Corporation
Or11ав11ение

Предисловие 31
Блаrодарности 37
Об авторах 40
Ч асть 1. Инно вацио нные стратегии 41
Глава 1. Как выбраться из ямы 43
Глава 2. Принцип малых шаrов 63
Глава 3. Домашние животные и крупный роrатый скот 75
Глава 4. Инфраструктура как код 93

Часть 11. Управление парком раб очих станций 115


Глава 5. Архитектура рабочей станции 117
Глава 6. Стратеrии управления аппаратным
обеспечением рабочих станций 138
Глава 7. Жизненный цикл рабочей станции 153
Глава 8. Стратеrии инсталляции операционных систем 172
Глава 9. Службы рабочей станции 191
Глава 10. Лоrистика парка рабочих станций 206
Глава 11. Стандартизация рабочих станций 222
Глава 12. Наем новых сотрудников 230
Ч асть 111. Серверы 247
Глава 13. Стратеrии управления аппаратным обеспечением серверов 249
Глава 14. Характеристики серверноrо оборудования 273
Глава 15. Спецификации аппаратноrо обеспечения серверов 293
Ч асть IV. Службы 309
Глава 16. Требования к службам 311
Глава 17. Планирование и разработка служб 332
rлава 18. Отказоустойчивость служб и шаблоны производительности 347
Глава 19. Развертывание службы: основы 361
Глава 20. Развертывание службы: методолоrия DevOps 378
Глава 21. Преобразование службы 396
Глава 22. Аварийное восстановление и целостность данных 408

Ч асть V. Инфраструктура 417


Глава 23. Сетевая архитектура 419
Глава 24. Сетевые операции 450
rлава 25. Обзор центров обработки данных 466
Глава 26. Работа центров обработки данных 475
Ч асть VI. Справочные службы и поддержка 497
Глава 27. Поддержка клиентов 499
Глава 28. Обработка отчетов об инцидентах 517
6 Оглавление

Глава 29. Отладка 539


Глава 30. Исправление раз и навсеrда 551
rлава 31. Документация 560
Ч асть VII. Процессы изменений 573
Глава 32. Управление изменениями 575
Глава 33. Обновления серверов 593
Глава 34. Технические перерывы 616
rлава 35. Централизация 642
Глава 36. Рекомендации по централизации 648
Глава 37. Централизация служб 660

Часть VIII. Рекомендации по работе служб 669


Глава 38. Мониторинr служб 671
Глава 39. Пространства имен 692
Глава 40. Службы имен 710
Глава 41. Служба электронной почты 727
Глава 42. Служба печати 746
Глава 43. Хранение данных 756
Глава 44. Резервное копирование и восстановление 788
Глава 45. Репозитории проrраммноrо обеспечения 818
Глава 46. Веб-службы 843
Часть IX. М етоды управления 861
Глава 47. Этика 863
Глава 48. Орrанизационные структуры 881
Глава 49. Восприятие и заметность 903
rлава 50. Управление временем 923
Глава 51. Общение и переrоворы 935
Глава 52. Быть счастливым 948
Глава 53. Наем системных администраторов 962
Глава 54. Увольнение системных администраторов 985

Часть Х. Как повысить эффективность работы 997


Глава 55. Качество обслуживания 999
Глава 56. Оценки производительности 1014
Эпилоr 1040
Часть XI. Прило жения 1041
Приложение А. Что делать, если 1043
Приложение Б. Роли системноrо администратора 1066
Библиоrрафия 1089
Предметный указатель 1093
Содерж ание

Предисловие 31
Для кого предназначена эта книга 31
Основные принципы 32
Кто такой системный администратор 33
Важность системного администрирования 33
Структура книги 34
Изменения в третьем издании 35
Что дальше 36

Блаrодарности 37
За третье издание 37
За второе издание 37
За первое издание 38

Об авторах 40

Часть 1. Инновационные стратегии 41


Глава 1. Как выбраться из ямы 43
1 .1 . Организация системы WIP 44
1 .1 .1 . Системы :iаявок 45
1 .1 .2. Методология Kanban 48
1 . 1 .3. Система :iаявок и методология Kanban 52
1 .2. Устранение пожирателей времени 52
1 .2.1 . Инсталляция и настройка операционной системы 53
1 .2.2. Развертывание программного обеспечения 54
1 .3. Методология DevOps 56
1 .4. Методология DevOps без разработчиков 56
1 .5. Узкие места 57
1 .6. Первые шаги 60
1 .7. Резюме 61
Упражнения 62

Глава 2. Принцип малы х шаrов 63


2.1 . Аналогия с плотником 63
2.2. Устранение адского месяца 64
2.3. Повышение эффективности аварийного восстановления 66
2.4. Стартуйте рано и часто 69
2.5. Резюме 73
Упражнения 74
8 Содержание

Глава 3. Домашние животные и крупный роrатый скот 75


3.1. Аналогия с домашними животными и крупным рогатым скотом 75
3.2. Масштабирование 77
3.3. Настольные компьютеры как рогатый скот 78
3.4. Аппаратные средства сервера как рогатый скот 79
3.5. состояние домашних животных 81
3.6. Изоляция состояния 82
3.7. Общие процессы 85
3.8. Откладывание изменений до конца процесса 89
3.9. Автоматизация 90
3.10. Резюме 91
Упражнения 92
Глава 4. Инфраструктура как код 93
4.1. Программируемая инфраструктура 94
4.2. Отслеживание изменений 94
4.3. Выгоды инфраструктуры как кода 97
4.4. Принципы инфраструктуры как кода 100
4.5. Инструментальные средства управления конфигурацией 101
4.5.1 . Декларативный или императивный язык 102
4.5.2. Идемпотентность 103
4.5.3. Предохранители и инструкции 104
4.6. Пример инфраструктуры как системы кодов 105
4.6.1. Конфигурирование клиента DNS 105
4.6.2. Простой веб-сервер 105
4.6.3. Сложное веб-приложение 106
4.7. Применение стратегии iAC в вашей организации 109
4.8. Инфраструктура как код для усиленного сотрудничества 1 10
4.9. Недостатки инфраструктуры как кода 1 10
4.10. Мифы об автоматизации 111
4.1 1 . Резюме 112
Упражнения 113
Часть 11. Управление парком рабочих станций 115
Глава 5 . Архитектура рабочей станции 117
5.1. Взаимозаменяемость 118
5.2. Аппаратное обеспечение 120
5.3. Операционная система 120
5.4. Сетевая конфигурация 122
5.4.1. Динамическая конфигурация 1 22
5.4.2. Жестко кодированная конфигурация 122
5.4.3. Гибридная конфигурация 123
5.4.4. Применимость 123
5.5. Учетные записи и авторизация 124
5.6. Хранилище данных 126
5.7. Обновления операционной системы 1 30
5.8. Безопасность 132
5.8.1 . Кража 132
5.8.2. Вредоносное ПО 133
Содержание 9

5.9. Ведение журнала 135


5.10. Резюме 136
Упражнения 136

Глава 6. Стратегии управления аппаратным


обеспечением рабочих станций 138
6.1 . Физические рабочие станции 138
6.1.1. Ноутбук или настольный ПК 138
6.1 .2. Выбор поставщика 139
6.1 .3. Выбор линии продукции 140
6.2. Инфраструктура виртуальных рабочих столов 142
6.2.1. Сниженные затраты 143
6.2.2. Простота эксплуатации 143
6.2.3. Постоянная и непостоянная память 144
6.3. Использование собственных устройств 147
6.3.1. Стратегии 148
6.3.2. Плюсы и минусы 148
6.3.3. Безопасность 149
6.3.4. Дополнительные расходы 149
6.3.5. Удобство использования 150
6.4. Резюме 151
Упражнения 151

Глава 7. Жизненный циКll рабоче й станции 153


7.1 . Жизненный цикл машины 153
7.2. Инсталляция операционной системы 156
7.3. Конфигурирование операционной системы 156
7.3.1. Системы управления конфигурацией 156
7.3.2. Объекты групповой политики Microsoft 158
7.3.3. Конфигурация DHCP 158
7.3.4. Установка пакета 159
7.4. Обновление системного программного обеспечения и приложений 159
7.41. Сравнение процессов обновления и инсталляции 160
7.4.2. Методы обновления 162
7.5. Вносите изменения осторожно 164
7.6. Утилизация 166
7.6.1 . Бухгалтерские задачи 167
7.6.2. Технические задачи, связанные с выводом из эксплуатации 168
7.3.3. Технические операции, связанные с защитой данных 168
7.6.4. Физические задачи 169
7.7. Резюме 170
Упражнения 170
Глава 8. Стратегии инсталляции операционных систем 172
8.1 . Согласованность важнее совершенства 1 73
8.2. Стратегии инсталляции 177
8.2.1 . Автоматизация 177
10 Содержание

8.2.2. Клонирование 178


8.2.3. Ручная инсталляция 180
8.3. Разработка тест-ориентированой конфигурации 182
8.4. Пошаговая автоматизация 183
8.5. Когда не следует автоматизировать 187
8.6. Поддержка поставщиков при инсталляции операционной системы 187
8.7. Следует ли доверять инсталляции поставщика 188
8.8. Резюме 189
Упражнения 189
Глава 9. Службы рабочей станции 191
9.1. Определение базовой услуги 191
9.1 .1. Подходы к определению платформы 192
9.1.2. Выбор приложения 193
9.1 .3. Использование базы CMDB 194
9.2. Циклы обновления 194
9.2.1 . Выбор подхода 195
9.2.2. Формализация политики 196
9.2.3. Согласование с амортизацией основных средств 196
9.3. Уровни поддержки 198
9.4. Рабочие станции как управляемая служба 202
9.5. Резюме 204
Упражнения 204
Глава 10. Логистика парка рабочих станций 206
10.1. Что видят работники 206
10.2. Чеrо не видят сотрудники 207
10.2.1 . Группа закупок 208
10.2.2. Группа подготовки 208
10.2.3. Группа доставки 210
10.2.4. Группа поддержки платформ 211
10.2.5. Сетевая группа 212
10.2.6. Инструменты 213
10.2.7. Управление проектом 214
10.2.8. Отдел по реализации программ 214
1 0.3. База данных управления конфигурацией 215
10.4. Логистика маломасштабных парков 218
10.4.1. Консультант-совместитель 219
10.4.2. Полноправные координаторы парка 219
10.5. Резюме 220
Упражнения 221
Глава 11. Стандартизация рабочих станций 222
1 1.1 . Привлекайте клиентов как можно раньше 223
1 1 .2. Выпускайте версии рано и часто 223
1 1 .3. Установите переходный период 224
1 1 .4. Одностороннее движение 225
Содержание 11

1 1 .5. Установите предельный срок 225


1 1 .6. Адаптация к корпоративной культуре 226
1 1 .7. Использование принципа наименьшего сопротивления 226
1 1 .8. Резюме 228
Упражнения 229

Глава 12. Наем новы х сотрудников 230


12.1. Создание хорошего первого впечатления 230
12.2. Обязанности в области информационных технологий 232
12.3. Пять факторов успеха при найме новых сотрудников 232
1 2.3.1 . Управляйте процессом с помощью расписания 232
1 2.3.2. Определите потребности перед прибытием 235
12.3.3. Осуществление процесса найма новых сотрудников 236
12.3.4. Общение между командами 237
12.3.5. Размышляйте и совершенствуйте процесс 238
12.4. Изменения темпа 240
12.5. Примеры использования 241
1 2.5.1. Худшая адаптация новых сотрудников 241
12.5.2. Процесс найма в компании Lumeta 242
1 2.5.3. Процесс найма новых сотрудников в компании Google 243
12.6. Резюме 245
Упражнения 246
Часть 111. Серверы 247
Глава 13. Стратеrии управления аппараПIЬ1 м
о беспеч ением серверов 249
1 3.1. Все яйца в одной корзине 250
13.2. Прекрасные снежинки 252
1 3.2.1 . Отслеживание ресурсов 253
1 3.2.2. Уменьшение вариаций 253
13.2.3. Глобальная оптимизация 254
1 3.3. Покупайте оптом, распределяйте частями 256
13.3.1. Управление виртуальными машинами 257
1 3.3.2. Динамическая миграция 258
13.3.3. Упаковка виртуальных машин 259
1 3.3.4. Резервная емкость для технического обслуживания 260
13.3.5. Унифицированное управление виртуальными
и физическими машинами 261
1 3.3.6. Контейнеры 262
1 3.4. Распределенные вычисления 263
1 3.5. Блейд-серверы 265
1 3.6. Облачные вычислительные службы 266
1 3.6.1. Что такое облако 266
13.6.2. Преимущества облачных вычислений 267
13.6.3. Програм мное обеспечение как услуга 269
1 3.7. Серверные устройства 269
1 3.8. Гибридные стратегии 270
12 Содержание

1 3.9. Резюме 270


Упражнения 271
Глава 14. Х арактеристики серв ерноrо оборудования 273
14.1. Сравнение рабочих станций и серверов 274
14.1 .1 . Различия в дизайне аппаратного обеспечения сервера 274
14.1 .2. Особенности управления серверной операционной системой 276
14.2. Надежность сервера 278
14.2.1 . Уровни избыточности 278
14.2.2. Целостность данных 278
Массив RAID 278
Альтернативные подходы 279
14.2.3. Компоненты с возможностью горячей замены 280
14.2.4. Серверы должны быть установлены в машинном зале 281
1 4.3. Дистанционное управление серверами 282
14.3.1 . Интегрированное внеполосное управление 283
14.3.2. Неинтегрированное внеполосное управление 283
Дистанционное управление электропитанием 283
Удаленная консоль с переключателем IP-KVM 284
Удаленная консоль с последовательными консолями 284
14.4. Отдельные административные сети 285
14.5. Контракты на обслуживание и запасные части 286
14.5.1. Соглашение об уровне обслуживания поставщика 286
14.5.2. Запасные части 288
14.5.3. Отслеживание контрактов на обслуживание 288
14.5.4. Перекрестная доставка 289
14.6. Выбор поставщиков с опытом работы на сервере 290
14.7. Резюме 291
Упражнения 291
Глава 15. Спецификации аппаратного обеспечения с ерверов 293
15.1. Модели и линейки продукции 294
1 5.2. Детали аппаратного обеспечения сервера 294
15.2.1. Центральный процессор 295
Несколько процессоров и ядер 295
Примеры приложений 297
Другие типы центральных процессоров 298
15.2.2. Память 299
Кеш-память 299
Архитекrура NUMA 301
Область подкачки 302
15.2.3. Сетевые интерфейсы 303
15.2.4. Диски: аппаратное обеспечение в сравнении
с программным обеспечением RAID 303
Программное обеспечение RAID 304
Аппаратное обеспечение RAID 304
15.2.5. Источники питания 305
1 5.3. От чего следует отказаться 306
Содержание 13

15.4. Резюме 307


Упражнения 308
Часть IV. Службы 309
Глава 16. Треб ования к службам 311
16.1 . Службы образуют среду 312
16.2. Установочное совещание 313
16.3. Сбор письменных требований 314
1 6.4. Требования заказчика 316
16.4.1 . Описание функций 316
16.4.2. Вопросы для ответа 317
1 6.4.3. Соглашения об уровне обслуживания 317
16.4.4. Обработка сложных запросов 318
16.5. Объем, календарный план и ресурсы 319
16.6. Эксплуатационные требования 320
16.6.1 . Наблюдаемость системы 320
16.6.2. Дистанционное и центральное управление 320
16.6.3. Уменьшение или увеличение размера службы 321
16.6.4. Обновление программного обеспечения 322
16.6.5. Технологическое окружение 323
16.6.6. Модель поддержки 324
16.6.7. Запросы на обслуживание 324
1 6.6.8. Аварийное восстановление 325
16.7. Открытая архитектура 326
16.8. Резюме 330
Упражнения 330

Глава 17. Планирование и разработка служб 332


1 7.1 . Инженерные основы 333
1 7.2. Простота 334
1 7.3. Проекты, сертифицированные разработчиками 335
17.4. Разработка зависимостей 336
17.4.1 . Основные зависимости 336
1 7.4.2. Внешние зависимости 336
1 7.4.3. Выравнивание зависимостей 338
1 7.5. Отделение имени хоста от имени службы 340
17.6. Поддержка 342
17.6.1 . Мониторинг 342
17.6.2. Модель поддержки 343
1 7.6.3. Модель запроса на обслуживание 344
1 7.6.4. Документация 344
1 7.7. Резюме 345
Упражнения 346

Глава 18. Отказоустойчивость служб и шаблоны


производительности 347
18.1. Схемы проектирования избыточности 348
18.1 .1. Шаблон "главный-подчиненный" 348
14 Содержание

18.1.2. Балансировщики нагрузки и реплики 349


18.1.3. Реплики и совместное состояние 350
18.1 .4 Производительность или отказоустойчивость? 351
18.2. Производительность и масштабирование 352
18.2.1 . Анализ потока данных для масштабирования 354
18.2.2. Пропускная способность по сравнению с задержкой 356
18.3. Резюме 359
����� �

Глава 19. Развертывание службы: основы 361


19.1 . Будьте готовы к проблемам 361
19.2. Шестиэтапный процесс запуска 362
19.2.1 . Шаг 1 . Определение списка готовности 363
19.2.2. Шаг 2. Работа со списком 366
19.2.3. Шаг 3. Запуск бета-службы 367
19.2.4. Шаг 4. Запуск службы в производство 368
19.2.5. Шаг 5. Извлечение уроков 369
19.2.6. Шаг 6. Повторение 370
19.3. Анализ готовности к запуску 371
19.3.1. Критерии готовности к запуску 371
19.3.2. Критерии запуска образца 372
19.3.3. Организационное обучение 372
19.3.4. Техническое обслуживание LRC 373
19.4. Календарь запусков 374
19.5. Общие проблемы запуска 374
19.5.1. Нарушение процессов на этапе производства 374
19.5.2. Неожиданные методы доступа 375
19 .5.3 Недоступность производственных ресурсов 375
19.5.4. Новые технологические сбои 375
19.5.5. Огсутствие обучения пользователей 376
19.5.6. Огсутствие резервных копий 376
19.6. Резюме 376
Упражнения 377
Глава 20. Разв ертывание службы: метод олоrия DevOps 378
20.1 . Непрерывная интеграция и развертывание 379
20.1.1. Порядок запуска тестов 379
20.1.2. Классификация запусков 380
20.2. Приложение с минимальной функциональностью 382
20.3. Быстрый выпуск с помощью готового программного обеспечения 384
20.3.1. Тестирование перед развертыванием 384
20.3.2. Показатели времени до развертывания 386
20.4. Клонирование производственной среды 386
20.5. Пример: программное обеспечение инфраструктуры DNS/DHCP 387
20.5.1. Проблема 388
20.5.2. Желаемое конечное состояние 389
20.5.3. Первый этап 389
20.5.4. Второй этап 390
Содержание 15

20.6. Запуск с переносом данных 391


20.7. Управление самообновляющимся программным обеспечением 393
20.8. Резюме 394
Упражнения 395

Глава 21. Преобразование службы 396


21.1. Сведение вмешательства к м инимуму 397
21.2. Слои и столбцы 398
21 .3. Поддержка поставщиков 400
21 .4. Коммуникация 400
21 .5. Обучение 401
21 .6. Постепенное развертывание 401
21 .7. Большой скачок: делаем все сразу 402
21 .8. План отступления 405
21.8.1. Немедленный откат 405
21.8.2. Точка принятия решения 406
21.9. Резюме 407
Упражнения 407

Глава 22. Аварийное восстановление и целостность данных 408


22.1 . Анализ рисков 409
22.2. Юридические обязательства 410
22.3. Ограничение ущерба 410
22.4. Подготовка 411
22.5. Целостность данных 413
22.6. Избыточные объекты 414
22.7. Бедствия с точки зрения безопасности 414
22.8. Связи со средствами массовой информации 415
22.9. Резюме 415
Упражнения 416

Часть V. Инфраструктура 417

Глава 23. Сетевая архитектура 419


23.1 . Физическая или логическая сеть 419
23.2. Модель OSI 420
23.3. Проводные офисные сети 421
23.2.1. Физическая инфраструктура 422
23.2.2. Логическая схема 423
23.3.3. Управление доступом к сети 425
23.3.4. Координаты для служб экстренной помощи 425
23.4. Беспроводные офисные сети 426
23.4.1. Физическая инфраструктура 426
23.4.2. Логический дизайн 426
23.5. Сети центров обработки данных 428
23.5.1. Физическая инфраструктура 429
23.5.2. Логическая схема 432
16 Содержание

23.6. Стратеrии WAN 433


23.6.1. Тополоrия 434
23.7. Маршруrизация 439
23.7.1. Статическая маршрутизация 439
23.7.2. Внуrренний протокол маршруrизации 439
23.7.3. Протокол внешних шлюзов 440
23.8. Досrуп к Интернету 440
23.8.1 . Исходящие соединения 440
23.8.2. Входящие подключения 441
23.9. Корпоративные стандарты 442
23.9.1 . Лоrическая схема 442
23.9.2. Физическая струкrура 443
23.10. Проrраммно-определяемые сети 445
23.1 1 . Протокол 1Pv6 445
23.11.1. Потребность в протоколе 1Pv6 446
23.1 1 .2. Развертывание протокола 1Pv6 446
23.12. Резюме 448
Упражнения 449

Глава 24. С етевы е операции 450


24.1. Мониторинr 450
24.2. Управление 451
24.2.1 . Досrуп и журнал аудита 452
24.2.2. Жизненный цикл 452
24.2.3. Управление конфиrурацией 454
24.2.4. Версии проrраммноrо обеспечения 455
24.2.5. Процесс развертывания 455
24.3. Документация 456
24.3.1. Проектирование и реализация сетей 456
24.3.2. Система DNS 457
24.3.3. Система CMDB 458
24.3.4. Маркировка 458
24.4. Помержка 458
24.4.1 . Инструменты 459
24.4.2. Орrанизационная структура 461
24.4.3. Сетевые службы 463
24.5. Сводка 464
Упражнения 465

Глава 25. Обзор центров обработки данны х 466


25.1 . Строительство, аренда или ауrсорсинr 467
25.1.1. Строительство 467
25.1.2. Аренда 467
25.1.3. Ауrсорсинr 468
25.1.4. Отказ от центра обработки данных 468
25.1.5. Гибрид 468
Содержание 17

25.2. Требования 469


25.2.1. Требования бизнеса 469
25.2.2. Технические требования 471
25.3. Сводка 473
Упражнения 474

Глава 26. Работа центров обраб отки данных 475


26.1 . Управление производительностью 475
26.1.1 . Место в стойке 476
26.1 .2. Энергопитание 478
26.1.3. Электропроводка 480
26.1.4. Сеть и консоль 481
26.2. Управление жизненным циклом 481
26.2.1. Инсталляция 481
26.2.2. Перемещение, добавление и изменение 482
26.2.3. Техническое обслуживание 482
26.2.4. Вывод из эксплуатации 483
26.3. Соединительные кабели 483
26.4. Маркировка 486
26.4.1. Маркировка местоположения стойки 487
26.4.2. Маркировка соединительных кабелей 487
26.4.3. Маркировка сетевого оборудования 489
26.5. Доступ к консоли 490
26.6. Рабочее место 491
26.7. Инструменты и расходные материалы 492
26.7.1 . Инструменты 492
26.7.2. Запчасти и расходные материалы 493
26.7.3. Парковочные места 494
26.8. Резюме 495
Упражнения 496
Часть VI. Справочные службы и поддержка 497
Глава 27. Поддержка клиентов 499
27.1. Наличие службы поддержки 499
27.2. Дружелюбие 501
27.3. Оrражение корпоративной культуры 502
27.4. Наличие достаточного количества персонала 502
27.5. Определение полномочий поддержки 504
27.6. Указание способа получения помощи 507
27.7. Определение процессов для персонала 507
27.8. Создание процесса эскалации 508
27.9. Письменное определение чрезвычайной ситуации 508
27.10. Поставка программного обеспечения для отслеживания запросов 509
27.11. Статистические улучшения 512
27.12. Внеурочные и круглосуточные услуги 513
27.13. Лучшая реклама для службы поддержки 514
27.14. Разные службы поддержки для разных нужд 515
18 Содержание

27.15. Резюме 515


Упражнения 516

Глава 28. Обраб отка отчетов об инцидентах 517


28.1. Обзор процесса 518
28.2. Фаза А - этап 1 . Приветствие 520
28.3. Фаза Б. Идентификация проблемы 521
28.3.1 . Этап 2. Классификация проблем 521
28.3.2. Этап 3. Заявление о проблеме 523
28.3.3. Этап 4. Верификация проблемы 525
28.4. Фаза В. Планирование и реализация 526
28.4.1 . Этап 5. Предложение решений 526
28.4.2. Этап 6. Выбор решения 527
28.4.3. Этап 7. Реализация 528
28.5. Фаза Г. Проверка 529
28.5.1 Этап 8. Проверка исполнителем 529
28.5.2. Этап 9. Проверка клиентом/закрытие заявки 530
28.6. Опасность пропустить этап 531
28.7. Оптимизация обслуживания клиентов 532
28.7.1 . Обучение на основе модели 533
28.7.2. Целостное улучшение 533
28.7.3. Повышение уровня знаний клиентов 533
28.7.4. Специальные объявления о серьезных сбоях 534
28.7.5 Анализ тенденций 534
28.7.6. Клиенты, знающие процесс 536
28.7.7. Архитектура, отражающая процесс 536
28.8. Резюме 537
Упражнения 538

Глава 29. Отладка 539


29.1 . Понимание проблемы клиента 539
29.2. Исправление причины, а не симптома 541
29.3. Будьте систематичными 541
29.4. Наличие правильных инструментов 543
29.4.1. Обучение - самый важный инструмент 543
29.4.2. Понимание базовой технолоrии 544
29.4.3. Выбор правильных инструментов 545
29.4.4. Инструменты оценки 547
29.5. Всестороннее понимание системы 547
29.6. Резюме 549
Упражнения 550

Глава 30. Исправление раз и навсеrда 551


30. 1 . История: неверно настроенные серверы 551
30.2. Избеrайте временных исправлений 553
30.3. Учитесь у плотников 555
30.4. Автоматизация 557
Содержание 19

30.5. Резюме 559


Упражнения 559

rлава 31. Докуменг ация 560


31.1 . Что нужно документировать 561
31.2. Простой шаблон для начала работы 561
31.3. Простые источники для документации 563
31 .3.1 . Сохранение скриншотов 563
31.3.2. Копирование содержания окна консоли 563
31 .3.3. Использование электронной почты 564
31 .3.4. Изучение заявок 564
31.4. Сила контрольных списков 565
31 .5. Вики-системы 566
31 .6. Возможность поиска 567
31.7. Проблемы внедрения 568
31.8. Система управления контентом 569
31 .9. Культура отношений 569
31.10. Классификация и структура 570
31.1 1. Дополнительное применение документации 570
31.12. Ссылки на внешние источники 571
31.13. Резюме 571
Упражнения 572
Ч асть V II. Процессы изменений 573
Г лава 32. Управление изменениями 575
32.1 . Комитет по управлению изменениями 576
32.2. Обзор процесса 577
32.3. Предложение изменений 578
32.4. Изменение классификаций 578
32.5. Выявление и количественное определение рисков 579
32.6. Техническое планирование 580
32.7. Составление rрафика 582
32.8. Коммуникация 583
32.9. Иерархия комитетов по управлению изменениями 585
32.10. Запрет на изменения 586
32.1 1 . Управление rрупповыми изменениями 588
32.11 . 1 . Избеrайте изменений по пятницам 589
32.1 1 .2. Предотвращение коллизий 590
32.1 1 .3. История изменений 590
32.12. Начинайте использовать хранилище Git 590
32.13. Резюме 592
Упражнения 592

Глава 33. Обновления с ерверов 593


33.1. Процесс обновления 593
33.2. Этап 1 . Разработка контрольноrо списка услуr 594
33.3. Этап 2. Проверка совместимости проrраммноrо обеспечения 596
20 Содержание

33.3.1 . Обновление программного обеспечения


до обновления операционной системы 597
33.3.2. Обновление программного обеспечения после обновления
операционной системы 597
33.3.3. Откладывание обновлений или изменений
программного обеспечения 598
33.4. Этап 3. Разработка проверочных тестов 598
33.5. Этап 4. Выбор стратегии обновления 601
33.5.1 . Скоросп, 602
33.5.2. Риск 602
33.5.3. Нарушение работы конечного поль:ювателя 603
33.5.4. Усилия 603
33.6. Этап 5. Напишите подробный план внедрения 604
33.6.1. Добавление служб во время обновления 604
33.6.2. Удаление службы во время обновления 604
33.6.3. Старые и новые версии на одной машине 605
33.6.4. Выполнение генеральной репетиции 605
33.7. Этап 6. Напишите план отката 606
33.8. Этап 7. Выберите технический перерыв 606
33.9. Этап 8. Объямение об обновлении 608
33.10. Этап 9. Выполнение тестов 608
33.1 1 . Этап 10. Блокировка клиентов 609
33.12. Этап 1 1 . Одна голова хорошо, а две - лучше 610
33.13. Этап 12. Проверьте свою работу 610
33.14. Этап 1 3. Если ничего не выходит, выполните откат 611
33.15. Этап 14. Восстановление доступа клиентов 611
33.16. Этап 15. Сообщение о завершении/откате 61 2
33.17. Резюме 614
Упражнения 615

Глава 34. Технические пер ерывы 616


34.1. Обзор процесса 617
34.2. Получение одобрения руководства 617
34.3. Планирование технических перерывов 619
34.4. Планирование работ по обслуживанию 620
34.5. Выбор руководителя полета 620
34.6. Управление предложениями об изменениях 622
34.6.1 . Образец предложения по изменению:
обновление сервера SecurID 622
34.6.2. Образец предложения по изменению:
миграция хранилища 624
34.7. Разработка общего плана 625
34.8. Отключение доступа 626
34.9. Обеспечение механизмов и координации 627
34.9.1 . Последовательность отключения и заrружи 627
34.9.2. КУМ, служба консоли и LOM 629
34.9.3. Связь 630
Содержание 21

34.10. Сроки завершения изменений 632


34. 1 1 . Комплексное тестирование системы 633
34.12. Сообщение после техобслуживания 634
34.13. Возобновление удаленного доступа 635
34.14. Будьте на виду следующим утром 635
34.15. Разбор полетов 636
34.16. Обучение нового руководителя полета 636
34.17. Анализ тенденций исторических данных 637
34.18. Обеспечение ограниченной доступности 637
34.19. Компании высокой доступности 638
34.19.1 . Сходства 638
34.19.2. Различия 639
34.20. Резюме 640
Упражнения 641
rлава 35. Централизация 642
35.1 . Обоснование реорганизации 643
35.1.1. Обоснование централизации 643
35.1 .2. Обоснование децентрализации 643
35.2. Подходы и гибриды 644
35.3. Резюме 646
Упражнения 647
Глава 36. Рекомендации по централизации 648
36.1. Архитектура 648
36.2. Безопасность 648
36.2.1. Авторизация 650
36.2.2. Соединения с внешней сетью 650
36.2.3. Предотвращение утечки данных 650
36.3. Инфраструктура 651
36.3.1 . Центры обработки данных 651
36.3.2. Сетевое взаимодействие 652
36.3.3. Управление пространством IР-адресов 653
36.3.4. Управление пространством имен 653
36.3.5. Свя:�ь 654
36.3.6. Управление данными 655
36.3.7. Мониторинг 655
36.3.8. Ведение журнала 656
36.4. Поддержка 656
36.4.1 . Служба поддержки 657
36.4.2. Поддержка конечных пользователей 657
36.5. Закупки 658
36.6. Лабораторная среда 658
36.7. Резюме 659
Упражнения 659
rлава 37. Централизация служб 660
37.1. Анализ текущего решения 660
37.2. Детальный план 662
22 Содержание

37.3. Получите поддержку руководства 662


37.4. Устраните проблемы 663
37.5. Обеспечение отличного обслуживания 663
37.6. Начинайте медленно 664
37.7. Ищите простейшие решения 664
37.8. Когда выполнять децентрализацию 665
37.9. Управление децентрализованными службами 666
37.10. Резюме 668
Упражнения 668
Часть VIII .Рекомендации по р аботе служб 669
Глава 38. Мониторинг служб 671
38.1. Виды мониторинга 672
38.2. Создание системы мониторинга 673
38.3. Исторический мониторинг 673
38.3.1 . Сбор данных 674
38.3.2. Хранение данных 675
38.3.3. Просмотр данных 675
38.4. Мониторинг в реальном времени 676
38.4.1 . Протокол SNMP 677
38.4.2. Обработка журналов 679
38.4.3. Механизм оповещения 679
38.4.4. Эскалация 682
38.4.5. Системы активного мониторинга 682
38.5. Масштабирование 683
38.5.1. Установка приоритетов 684
38.5.2. Каскадные оповещения 684
38.5.3. Координация 685
38.6. Централизация и досrупность 685
38.7. Тотальный мониторинг 686
38.8. Сквозное тестирование 686
38.9. Мониторинг времени ответа приложения 688
38.10. Мониторинг соблюдения правил 688
38.11 . Метамониторинг 689
38.12. Резюме 690
Упражнения 691

Глав а 39. Пространства имен 692


39.1. Что такое пространство имен 692
39.2. Основные правила пространств имен 693
39.3. Выбор имен 693
39.4. Объединение пространств имен 697
39.5. Управление жизненным циклом 698
39.6. Повторное использование 699
39.7. Использование 700
39.7.1. Сфера действия 700
39.7.2. Согласованность 703
39.7.3. Авторитетность 706
Содержание 23

39.8. Федеративная идентификация 707


39.9. Резюме 708
Упражнения 709
Глава 40. Службы имен 710
40.1 . Данные службы имен 710
40. 1 . 1 . Данные 71 1
40.1 .2. Согласованность 711
40. 1 .3. Авторитетный источник 711
40.1 .4. Объем и масштабирование 712
40.2. Надежност1, 712
40.2.1 . Служба DNS 713
40.2.2. Служба DHCP 716
40.2.3. Серверы LDAP 716
40.2.4. Аутентификация 717
40.2.5. Аутентификация, авторизация и учет 718
40.2.6. Базы данных 719
40.3. Политика доступа 720
40.4. Изменение политик 721
40.5. Процедуры изменения 722
40.5.1 . Автоматизация 723
40.5.2. Автоматизация самообслуживания 724
40.6. Централизованное управление 724
40.7. Резюме 726
Упражнения 726
Глава 41. Служба электронной почты 727
41 . 1 . Политика конфиденциальности 728
41 .2. Пространства имен 728
41 .3. Надежность 729
41 .4. Простота 731
41.5. Блокирование спама и вирусов 733
41 .6. Универсальность 734
41 .7. Автоматизация 735
41 .8. Мониторинг 736
41.9. Избыточность 737
41.10. Масштабирование 737
41 . 1 1 . Проблемы безопасности 740
41.12. Шифрование 741
41 .13. Политика хранения электронной почты 741
41 .14. Коммуникация 742
41.15. Обработка бол1.ших списков 743
41.16. Резюме 744
Упражнения 745
Глава 42. Служба печати 746
42. 1 . Уровень централизации 746
42.2. Архитектура печати 748
42.3. Документация 751
24 Содержание

42.4. Мониторинг 752


42.5. Экологические проблемы 753
42.6. Уничтожение документов 754
42.7. Резюме 754
Упражнения 755
Глава 43. Хр анение данных 756
43.1 . Терминология 757
43.1.1. Ключевые компоненты отдельных дисков 757
43.1 .2. Технология RAID 758
43.1.3. Тома и файловые системы 760
43.1 .4. Непосредственно подключенное хранилище 760
43.1.5. Сетевое хранилище 761
43.1 .6. Сети хранения данных 761
43.2. Управление хранением 761
43.2.1 . Рассматривайте хранилища как ресурс сообщества 762
43.2.2. П роведение оценки потребностей хранения 763
43.2.3. Отображение групп в инфраструктуре хранения 765
43.2.4. Разработка политики инвентаризации запасных частей 766
43.2.5. Планирование будущего хранилища 767
43.2.6. У становление стандартов хранения 767
43.3. Хранение как служба 769
43.3.1 . Соглашения об обслуживании системы хранения 769
43.3.2. Надежность 770
43.3.3. Резервные копии 771
43.3.4. Мониторинг 774
43.3.5. П редостережения о системах SAN 776
43.4. Производительность 776
43.4.1 . RAID и производительность 777
43.4.2. Хранилище NAS и производительность 778
43.4.3. Твердотельные диски и производительность 778
43.4.4. Хранилища SAN и производительность 778
43.4.5. Оптимизация конвейера 779
43.5. Оценка новых решений для хранения данных 781
43.5.1. Скорость движения 781
43.5.2. Фрагментация 781
43.5.3. Пределы хранения: отставание плотности доступа к диску 782
43.5.4. Непрерывная защита данных 783
43.6. Общие проблемы хранения данных 784
43.6.1 . Большая физическая инфраструктура 784
43.6.2. Превышение времени ожидания 784
43.6.3. Поведение при перегрузке 785
43.7. Резюме 786
Упражнения 786
Глава 44. Резервное копиров ание и восстановление 788
44.1 . Начало работы 789
44.2. Причины восстановления данных 790
44.2.1. Случайное удаление файлов 791
Содержание 25

44.2.2. Огказ диска 792


44.2.3. Просмотр архивных данных 792
44.2.4. Проводите учебно-тренировочные занятия 793
44.3. Корпоративные инструкции 794
44.4. Соrлашение SLA и политика восстановления данных 795
44.5. Расписание резервноrо копирования 796
44.6. Планирование времени и емкости 801
44.6.1 . Скорость резервноrо копирования 802
44.6.2. Скорость восстановления 802
44.6.3. Базы данных высокой досrупности 803
44.7. Планирование расходных материалов 804
44.7.1 . Инвентаризация лент 805
44.7.2. Резервное копирование и внешнее хранилище 806
44.8. Проблемы с восстановлением 809
44.9. Автоматизация резервноrо копирования 810
44.10. Централизация 813
44. 1 1 . Изменения технолоrий 814
44.12. Резюме 815
Упражнения 817

Глава 45. Репозитории проrр аммного об еспечения 818


45.1. Типы репозиториев 819
45.2. Преимущества репозиториев 820
45.3. Системы управления пакетами 822
45.4. Структура пакета 823
45.4.1 . Метаданные и сценарии 823
45.4.2. Активная и пассивная инсталляции 823
45.4.3. Двоичные пакеты 824
45.4.4. Пакеты библиотек 824
45.4.5. Суперпакеты 824
45.4.6. Пакеты исходных кодов 825
45.5. Структура репозитория 826
45.5.1. Безопасность 827
45.5.2. Универсальный досrуп 828
45.5.3. Процесс деблокирования 829
45.5.4. Мноrоуровневые зеркала и тайники 829
45.6. Управление репозиторием 830
45.6.1 . Переупаковка общедосrупных пакетов 831
45.6.2. Переупаковка стороннеrо проrраммноrо обеспечения 832
45.6.3. Служба и поддержка 832
45.6.4. Репозиторий как служба 833
45.7. Клиент-репозиторий 834
45.7.1. Управление версиями 834
45.7.2. Огслеживание конфликтов 836
45.8. Создание среды 836
45.8.1 . Непрерывная интеrрация 837
45.8.2. Герметическая сборка 837
26 Содержание

45.9. Примеры репозитория 838


45.9.1. Поэтапный репозиторий программного обеспечения 838
45.9.2. Зеркало операционной системы 839
45.9.3. Управляемое зеркало операционной системы 840
45. 10. Резюме 841
Упражнения 841
Глава 46. Веб-службы 843
46.1 . Простые веб-серверы 844
46.2. Несколько веб-серверов на одном узле 845
46.2.1 . Масштабируемые методы 845
46.2.2. Протокол НТГРS 846
46.3. Соглашения об уровне обслуживания 846
46.4. Мониторинг 847
46.5. Масштабирование веб-служб 847
46.5.1. Горизонтальное масштабирование 847
46.5.2. Вертикальное масштабирование 848
46.5.3. Выбор метода масштабирования 849
46.6. Безопасность неб-служб 851
46.6.1 . Защищенные соединения и сертификаты 852
46.6.2. Защита приложения веб-сервера 854
46.6.3. Защита контента 854
46.6.4. Безопасность приложений 856
46.7. Управление контентом 858
46.8. Резюме 860
Упражнения 860
Часть IX. Методы управления 861
Глава 47. Этика 863
47. 1 . Информированное согласие 863
47.2. Этический кодекс 864
Этический кодекс системных администраторов 865
47.3. Руководства пользователей 866
47.4. Правила поведения привилегированных пользователей 866
47.5. Соблюдение авторских прав 868
47.6. Работа с правоохранительными органами 871
47.7. Формирование ожиданий о конфиденциальности и мониторинге 875
47.8. Приказ поступить незаконно или неэтично 877
47.9. В ыявление незаконной деятельности 878
47.10. Резюме 879
Упражнения 879
Глава 48. Организационные структуры 881
48. 1 . Определение размера 882
48.2. Модели финансирования 884
48.3. Влияние управленческой цепочки 887
48.4. Подбор навыков 889
48.5. Группы обслуживания инфраструктуры 891
Содержание 27

48.6. Поддержка клиентов 893


48.7. Служба поддержки 894
48.8. Аутсорсинг 895
48.9. Консультанты и подрядчики 896
48.10. Примеры организационных сrруктур 898
48.10.1. Небольшая компания 898
48.10.2. Компания среднего размера 898
48.10.3. Крупная компания 898
48.10.4. Компания электронной торговли 899
48.10.5. Университеты и некоммерческие организации 900
48. 1 1 . Резюме 901
Упражнения 901
Глава 49. Восприятие и заметность 903
49.1. Восприятие 903
49.1.1. Хорошее первое в печатление 904
49.1 .2. Оrношение, восприятие и пользователи 907
49.1.3. Согласование приоритетов с ожиданиями клиентов 909
49.1 .4. Системный адвокат 910
49.2. Заметносrь 914
49.2.1. Веб-страница состояния системы 914
49.2.2. Всrречи с руководством 915
49.2.3. Физическая заметносrь 916
49.2.4. Общие собрания 916
49.2.5. Информационные бюллетени 918
49.2.6. Рассылка для всех пользователей 919
49.2.7. Обеденный перерыв 920
49.3. Резюме 921
Упражнения 922
rлава 50. Управление временем 923
50.1 . Прерывания 923
50.1.1. Сосредоточьтесь 924
50.1 .2. Разделение дня 924
50.2. Завершение 924
50.3. Управление списками главных дел 925
50.4. Определение целей 927
50.5. Обрабатывайте электронную почту сразу 928
50.6. Предварительные компиляционные решения 929
50.7. Поиск свободного времени 930
50.8. Борьба с плохо организованными людьми 931
50.9. Борьба с медлительными бюрократам и 932
50.10. Резюме 933
Упражнения 934
Глава 51. Общение и переговоры 935
51.1. Общение 935
51.2. Я-утверждение 936
28 Содержание

51 .3. Активное слушание 936


51.3.1. Зеркальные утверждения 936
51.3.2. Обобщающие утверждения 938
51.3.3. Отражающие утверждения 939
51.4. Переговоры 940
51.4.1 . Выяснение ситуации 940
51.4.2. Установите формат встречи для переговоров 941
51 .4.3. Работа на взаимовыгодный результат 941
51.4.4. Планирование переговоров 941
51 .5. Дополнительные советы по ведению переговоров 943
51.5.1. Просите то, чего вы действительно хотите 943
51 .5.2. Не спорьте с самим собой 943
51.5.3. Не раскрывайте свою стратегию 944
51 .5.4. Отклоняйте первое предложение 944
51 .5.5. Используйте молчание как инструмент переговоров 945
51.6. Дополнительная литература 945
51.7. Резюме 946
Упражнения 946
Глава 5 2. Быть счастливым 948
52.1. Счастье 948
52.2. Принятие критики 949
52.3. Ваша группа поддержки 950
52.4. Ищите баланс между работой и личной жизнью 951
52.5. Профессиональное развитие 952
52.6. Оставайтесь технарями 952
52.7. Любите свою работу 953
52.8. Мотивация 954
52.9. Управление своим руководителем 956
52.10. Книги практических советов 959
52. 1 1 . Резюме 960
Упражнения 960
Глава 53. Наем системных администраторов 962
53.1. Должностная инструкция 963
53.2. Уровень навыков 965
53.3. Подбор кандидатов 965
53.4. Время 968
53.5. Психологическая совместимость 969
53.6. Группа собеседования 972
53.7. Процесс собеседования 973
53.8. Техническое собеседование 975
53.9. Нетехническое собеседование 979
53.10. Реклама должности 980
53.1 1 . Удержание сотрудни ков 981
53.12. Станьте заметными 982
53.13. Резюме 983
Упражнения 984
Содержание 29

Глава 54. Увольнение системных администраторов 985


54.1. Сотрудничайте с отделом кадров корпорации 986
54.2. Контрольный список задач при увольнении 987
54.3. Лишение доступа 987
54.3.1. Физический доступ 988
54.3.2. Удаленный доступ 989
54.3.3. Доступ к приложениям 989
54.3.4. Общие пароли 990
54.3.5. Внешние службы 990
54.3.6. Сертификаты и другие секреты 990
54.4. Логистика 991
54.5. Примеры 992
54.5.1. Мирный уход из компании 992
54.5.2. Увольнение начальника 992
54.5.3. Увольнение в учебном заведении 993
54.6. Поддержка инфраструктуры 994
54.7. Резюме 995
Упражнения 996

Часть Х. Как повысить эффективность работы 997

Глава 55. Качество о бслуживания 999


55.1 . Что такое высокий профессионализм 999
55.2. Как измерить качество 1000
55.3. Методология оценки 1 000
55.3.1. Эксплуатационные обязанности 1001
55.3.2. Рейтинги 1002
55.3.3. Вопросы оценки и схожести 1004
55.4. Оценка служб 1005
55.4.1. Определение критериев оценки 1005
55.4.2. Оценка каждой службы 1006
55.4.3. Сравнение результатов всех служб 1006
55.4.4. Выполнение результатов 1 007
55.4.5. Частота оценивания и планирования проектов 1007
55.5. Организационные оценки 1008
55.6. Уровни улучшения 1009
55.7. Начало работы 1010
55.8. Резюме 1011
Упражнения 1013

Глава 56. Оценки производительности 1014


56.1 . Обычные задачи 1015
56.2. Экстренное реагирование 1017
56.3. Мониторинг и показатели 1019
56.4. Планирование загрузки 1021
56.5. Управление изменениями 1023
56.6. Внедрение и удаление нового продукта 1024
30 Содержание

56.7. Развертывание и вывод служб из эксплуатации 1026


56.8. Производительность и эффективность 1028
56.9. предоставление службы: этап создания 1031
56.10. Предоставление службы: этап развертывания 1033
56. 1 1 . Уменьшение трудозатрат 1035
56.12. Готовность к стихийным бедствиям 1038
Эпилог 1040
Часть XI. Приложения 1041
Приложение А. Что делать, если 1043
Приложение Б. Р оли системного администратора 1066
Б.1. Типичные положительные роли 1066
Б.2. Отрицательные роли 1082
Б.3. Распределение ролей в группе 1084
Б.4. · Резюме 1087
Упражнения 1087
Би блиография 1089
Предметный указ атель 1093
Пр едисл овие

Это необычная книга. Она не о технике и програм мировании. Это книга


о стратегиях и концепциях, содержащая поучительные истории и неявное зна­
ние, которое накопилось за десятилетия опыта нашей работы в качестве систем­
ных администраторов.
Начинающие системные администраторы стараются выучить, какие команды
набирать на клавиатуре и какие кнопки нажимать. Однако по мере приобрете­
ния опыта они начинают осознавать, что намного важнее понимать, почему вы­
полняется то или иное действие и как организовать свою работу. Эти вопросы
ОТНОСЯТСЯ к стратегии.
Эта книга даст вам основу - образ мышления системного администратора,
а не узкие решения конкретных задач. Имея солидное основание, вы сможете
решать любые возникающие проблемы независимо от операционной системы,
разновидности компьютера или среды. Эта книга уникальна, потому что в ней
системное администрирование рассматривается в целом, тогда как большинство
других книг для системных администраторов сосредоточивается на обслужива­
нии определенного программного обеспечения. Однако с опытом все системные
администраторы начинают понимать, что крупномасштабные проблемы и реше­
ния в значительной степени независимы от платформы. После изучения этой
книги ваша точка зрения на работу системного администратора изменится.
Эта книга является первым томом серии. Она посвящена инфраструктуре
предприятия, поддержке клиентов и вопросам управления. В томе 2, Тhе Practice
of Cloud System Administration (ISBN:9780321943187), рассматриваются веб-операции
и распределенное вычисление.
В обоих томах нашел отражение наш опыт работы в качестве системных ад­
министраторов в самых разных организациях. Мы создавали новые компании,
помогали развивать корпоративные сети, работали как в небольших стартап­
компаниях, так и в университетах, испытывавших нехватку финансирования. Мы
имеем опыт работы в средних и крупных транснациональных корпорациях, где
слияния и поглощения порождали неожиданные проблемы. Мы были сотруд­
никами быстро развивающихся компаний, занимающихся коммерцией в Ин­
тернете, в которых типичными были проблемы широкой доступности, высокой
производительности и масштабирования. Мы также работали в консерватив­
ных компаниях, в которых использование высокой технологии ограничивалось
беспроводными телефонами. Внешне все эти очень разные компании сталкива­
ются с совершенно разными проблемами, однако внутренне они устроены оди­
наково и применяют одни и те же фундаментальные принципы.

Для кого предназначена эта книга


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

Младшие сисrемные админисrраторы получат предсrавление о принципах ра­


боты корпоративных сетей, своей роли в организациях и перспективах своей карье­
ры. Сисrемные админисrраторы среднего уровня научатся решать более сложные
задачи, а также cмoryr улучшить и упросrить работу корпоративной сети илучше
удовлетворить потребносrи клиеmов. Независимо от уровня подготовки читателя
эта книга поможет ему понять смысл его ежедневной работы и научит экономить
время, вырабатывать сrратегию, играть роль архитекторов и проектировщиков,
разрабатывать планы на будущее, договариваться с посrавщиками и взаимодей­
сrвовать с руководсrвом.
Все это знают сrаршие сисrемные администраторы, но об этом ничего не ска­
зано ни в одном справочнике по вашей операционной сисrеме.

О сновные приIЩипы
В этой книге мы придерживаемся следующих принципов.
• Автоматизация. Программное обеспечение должно заменить человечес­
кий труд. Автоматизация - крайне важный принцип. Мы не должны ре­
шать задачи; мы должны поддерживать работу сисrемы, которая решает
их вмесrо нас. Автоматизация повышает уровень единообразия и масшта­
бируемости, играет ключевую роль в ослаблении бремени сисrемного ад­
минисrрирования и усrраняет утомительные повторяющиеся задачи, пре­
досrавляя сисrемным админисrраторам больше времени для улучшения
обслуживания. Автоматизация начинается с точного определения повто­
ряющегося процесса, т.е. его документирования. Затем его можно будет
оптимизировать и программировать.
• Тактика малых шагов. Работу необходимо выполнять небольшими пор­
циями, а не большим куском. Эго позволяет бысrрее получать более качес­
твенные результаты с меньшими усилиями.
• Непрерывная интеграция. Группы должны взаимодейсrвовать между
собой, достигая более высоких результатов, вместо того чтобы выполнять
локальную оптимизацию, которая, возможно, не принесет пользы в более
крупном масштабе. Противоположность этого принципа - работа в изо­
лированных группах, иrnорирующих более крупную организацию.
• Системы самообслуживания. Инструментальные средства должны позво­
лять людям работать независимо друг от друга, без централизации управ­
ления. Общие службы должны образовывать платформу для предоставле­
ния услуг, а не управляющую структуру.
• Взаимодействие. Правильно подобранные люди могут решить бол1,ше
задач, чем а ппаратные средсrва или программное обеспечение. Вы долж­
ны тесно взаимодействовать с системными админисrраторами и своими
клиентами. Именно вы должны быть инициатором взаимодействия. Эгот
принцип гарантирует, что все стремятся к одним и тем же целям. Нехват­
ка взаимодейсrвия вызывает у людей беспокойство и раздражение. Кроме
того, взаимодействие подразумевает документацию. Докумеmация упро­
щает обслуживание и модернизацию систем . Хорошее взаимодействие
и надлежащая докумеmация также облегчают процесс передачи проекта
преемнику для дальнейшего обслуживания, когда вы переходите на новую
работу или получаете другую должность.
Предислов ие 33

Эти принципы универсальны. Они относятся ко всем уровням системы . Они


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

Кто такой системный администр атор


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

В ажность системного администрирования


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

Сейчас менеджеры имеют более реалистичное представление о компьютерах.


Пока люди не поставили персональные компьютеры на свои столы, мнение боль­
шинства о компьютерах диктовалось кинематографом : огромные, всезнающие,
самостоятельные чудо-машины.
Чем больше людей вступало в прямой контакт с компьютерами, тем более реа­
листическими становились ожидания от них. Тепер1, в фильмах показывают даже
самих системных администраторов. В классическом фильме Парк юрского периода,
вышедшем в 1993 году, впер11ые была показана ключевая рол1, системных админи­
страторов крупных систем. В этом фильме также показано, что зависимость от од­
ного человека ведет к беде. Информационные технологии - это командная игра.
Если бы только Деннис Недрай (Dennis Nedry) прочитал эту книrу!1
В бизнесе ничто не важно, если генеральный директор не считает, что это
важно. Генеральный директор распределяет финансирование и устанавливает
приоритеты. Теперь генеральные директора признают важность информацион­
ных технологий. В прошлом электронная почта была прероrативой технических
специалистов, а теперь руководители зависят от электронной почты и замечают
даже короткие перебои в ее работе. Массовые приготовления к 2000 году так­
же показали руководителям организаций, насколько сильно они стали зависеть
от компьютеров, насколько дорогим стало их обслуживание и как быстро сугубо
техническая проблема может стать серьезной угрозой. Большинство людей не
понимает, что им просто повезло, и считает, что проблема была предотвраще­
на благодаря неустанным усилиям многих людей. 63% американцев, принявших
участие в опросе CBS, полагают, что время и усилия, 3атраченные на устранение
потенциальных проблем, стоят этого. Новости, которые три ведущие телекомпа­
нии передавали в понедельник 3 января 2000 года, выражали ту же точку зрения.
В прошлом люди впервые сталкивались с компьютерам и уже в зрелом во:!­
расте и осваивали их с осторожностью. Теперь они используют компьютеры с са­
мого детства. Они постоянно сидят в социальных сетях, используя свои телефо­
ны. В результате, достигая высоких должностей, они ждут от компьютеров бол1,­
шеrо. Генеральные директора, на которых производила бол1,шое впечатление
автоматическая обработка платежной ведомости, ушли в прошлое. Им на смену
пришли люди, которые выросли, непрерывно рассылая сообщения вес1, день. Эта
новая волна менеджеров хочет вести весь бизнес с помощью своих телефонов.
Сейчас компьютеры важны как никогда. Если вы хотите, чтобы они работали,
причем работали хорошо, то должны понимать необходимость системного ад­
министрирования. Мы играем важную роль.

Структур а книги
Книга состоит из следующих частей.
• Часть I, "Инновационные стратегии" . В этой части показано, как сделать
следующий бол1.шой шаг как тем, кто изо всех сил пытается справлят1.ся
с потоком работы, так и тем, у кого все идет гладко.
• Часть 11, "Управление парком рабочих станций" . Эта часть охватывает
все аспекты использования ноутбуков и настольных компьютеров. В ней

1 Деннис Недрай (Dennis Nedry) - системный администратор, персонаж фильма "Парк


юрского периода". -Примеч. ред.
Предисловие 35

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


эти машины как серийные продукты.
• Часть Ш, "Серверы" . Эга часть посвящена вопросам управления а ппарат­
ными средствами сервера - от выбора стратегии работы сервера до аспек­
тов, которые делают машину сервером, и факторов, влияющих на выбор
аппаратных средств сервера.
• Часть IV, "Службы". В этой части рассматриваются проектирование, созда­
ние и запуск служб, переход пользователей от одной службы к другой, со­
здание надежных служб и планирование восстановления после сбоев.
• Часть V, "Инфраструктура" . Эга часть посвящена основной инфраструкту­
ре. Она содержит описание видов сетевой архитектуры и операций, а так­
же краткий обзор датацентричной стратегии и датацентричных операций.
• Часть VI, "Справочные службы и поддержка". В этой части рассматриваются
все аспекты, обеспечивающие эффективное обслуживание клиентов, вклю­
чая документацию, обработку сообщений о сбоях и организацию отладки.
• Часть VII, "Процессы изменений". В этой части описаны подходы к изме­
нению процессов управления и показано, как лучше всего управлять круп­
ными и малыми изменениями. Кроме того, здесь охвачены вопросы опти­
мизации поддержки за счет централизации обслуживания.
• Часть VIll, "Рекомендации по работе служб". Эга часть содержит всесто­
ронний обзор всех вопросов, которые необходимо учесть, организовывая
общедоступные службы. Она охватывает вопросы, связанные с мониторин­
гом, службам и и мен, электронной почтой, вебом, печатью, хранением, ре­
зервными копиями и программными хранилищами.
• Часть IX, "Методы управления". Эга часть предназначена для менеджеров
и других специалистов. В ней освещены такие темы, как этика, организа­
ционные структуры, восприятие, видимость, календарное планирование,
коммуникация, удовлетворенность, а также наем и увольнение системных
администраторов.
• Часть Х, "Как повысить эффективность работы". Эту часть должны про­
читать все менеджеры. В ней показано, как конструктивно оценить работу
группы системных администраторов, используя для прогнозирования мо­
дель технологической зрелости (Capability Maturity Model).
• Часть XI, "Приложения" . В этой части представлены два приложения.
В первом приведен список решений для типичных ситуаций, а во вто­
ром - краткий обзор положительных и отрицательных ролей в группе.

Изменения в тр етьем издании


Первые два издания получили много положительных рецензий и отзывов. Мы
стали популярными. Однако со временем содержание некоторых глав устарело.
Большинство наших смелых инновационных идей теперь стали общепринятой
практикой.
Первое издание, вышедшее в свет в августе 2001 года, было написано главным об­
разом в 2000 году, еще до того, как слово "Google" стало известным в каждой семье,
когда термин "современные вычисления" были синонимом многопользовательской
36 Пред и сл овие

системы Sun. Многие люди не имели досrупа к Интернету, а облака существова­


ли только в небе. Второе издание было выпущено в июле 2007 года. Оно сгладило
острые углы и заполнило некоторые пробелы, но было написано, когда методология
DevOps (Development and Operations разработка и операции) была все еще в за­
-

чаточном состоянии.
В третьем издании содержатся две дюжины совершенно новых глав; некоторые
главы глубоко переработаны, а остальные уrочнены с учетом современных знаний.
Относительно длинные главы разбиты на меньшие. Весь новый материал орга­
низован вокруг выбора стратегий. Кроме того, там, где это казалось нам особенно
полезным, мы ввели принципы DevOps и SRE (Site Reliabllity Engineering обес­
-

печение надежности информационных систем).


Если вы читали предыдущие издания и хотите выяснить, что в книге нового,
то обратите внимание на следующие разделы .
• Часть I, "Инновационные стратегии" (главы 1-4)
• Часть Il, "Управление парком рабочих станций" (главы 5-12)
• Часть Ш, "Серверы" (главы 1 3-15)
• Часть IV, "Службы" (главы 16--20 и 22)
• Глава 23, "Сетевая архитектура", и глава 24, "Сетевые операции"
• Глава 32, "Управление изменениями"
• Глава 35, "Централизация", глава 36, "Рекомендации по централизации",
и глава 37, "Централизация служб"
• Глава 43, "Хранение данных"
• Глава 45, "Репозитории программного обеспечения", и глава 46, "Веб-службы"
• Глава 55, "Качество обслуживания", и глава 56, "Оценки производительности"
В книгах, как и в программах, всегда есть ошибки. Список исправлений, 11мес-
те с новостями, рримечаниями и списком рассылок, к которому вы можете при­
соединиться, можно найти на нашем веб-сайте:
www . Everyt h ingS ysAdmi n . com

Что д альш е
В каждой главе освещается отдельная тема. Их можно читать в любом по­
рядке. Тем не менее мы тщательно продумали последовательность изложения,
чтобы книгу можно было читать от начала до конца. Как бы там ни было, мы
надеемся, что вы будете довольны. Мы многое узнали и получили большое удо­
вол1,ст11ие, работая над книгой. Итак, начнем.
Томас А. /lимончелли
Stack Overflow, Inc.
t om@ l imonce l l i . com
Кристина Дж. Хоган
chogan@ chogan . com
Страта Р. Чейлап
Virtual.Net, Inc.
s t ra t a @ v i rt u a l . net
Б лаг од арности

За тр еть е издание
Многие люди щедро делились с нами знаниями и морально поддерживали.
Мы хотим поблагодарить очень многих!
Мы благодарны всем, кто не жалел времени и сил, чтобы у нас была обшир­
ная обратная связь и множество предложений: Дереку Бейлинrу (Deгek J. Balling),
Стейси Фрай (Stacey Fгуе), Питеру Грейсу (Peter Grace), Джону Пеллману (John
Pellman), Джастину Попу (lustin Рор) и Джону Уиллису (John Willis).
Спасибо нашим друзьям, сотрудникам и экспертам, которые оказывали нам
поддержку, вдохновляли и делились знаниями: Джорджу Бичу (George Beech),
Стиву Блэру (Steve Blair), Кайлу Брандту (Kyle Brandt), Грэrу Брею (Greg Bray),
Нику Крейверу (Nick Craver), Джефу Далгасу (Geoff Dalgas), Мишель Фредетт
(Michelle Fredette), Дэвиду Фаллертону (David Fullerton), Дэну Гилмартину (Dan
Gilmartin), Трею Харрису (Trey Harris), Джейсону Харви (Jason Harvey), Марку
Хендерсону (Mark Henderson), Брайану Джену (Bryan Jen), Джину Киму (Gene
Kim), Томасу Линкину (Thomas Linkin), Шейну Маддену (Shane Madden), Джиму
Мореру (Jim Maurer), Кевину Монтрозу (Kevin Montrose), Стиву Муравски (Steve
Murawski), Ксавье Николе (Xavier Nicollet), Дэну О'Бойлу (Dan O'Boyle), Крэйrу
Петерсону (Craig Peterson), Джейсону Паниону (Jason Punyon), Майку Рембетси
(Mike Rembetsy), Нейлу Растону (Neil Ruston), Джейсону Шанцу (Jason Shantz),
Дагоберту Сорджелу (Dagobert Soergel), Каре Соулз (Kara Sowles), Майку Стоп­
пею (Mike Stoppay) и Джо Юн (Joe Youn).
Мы благодарим нашу группу редакторов в издательстве Addison-Wesley: Деб­
ру Вилльямс Коули (Debra Williams Cauley) за ее руководство; Майкла Терсто­
на (Michae\ Thurston), нашего выпускающего редактора, который получил сы­
рой материал и превратил ero в великолепную книrу; Ким Бодигхаймер (Kim
Boedigheimer), которая координировала наш календарный план; Лори Хьюз (Lori
Hughes), нашеrо мастера LaTeX; Джулию Нейхил (Julie Nahil), нашего техничес­
кого редактора; Джилл Хоббс (Jill Hobbs), нашу верстальщицу, а также Тэда Ло
(Ted Laux) за то, что сделал прекрасный предметный указатель!
Последними по очереди, но не по значению, мы благодарим свои семьи, ко­
торые страдали в течение многих лет, пока мы пренебрегали другим и обязаннос­
тями, работая над этой книгой. Спасибо за понимание! Мы обещаем, что это -
наша последняя книга. Правда!

За второе издание
Мы также говорим, что второе ицание не смогло бы выйти в свет без помощи
и поддержки Ли Дэмона (Lee Damon), Натана Дича (Nathan Dietsch), Бенджа­
мина Фива (Benjamin Feen), Стивена Харриса (Stephen Harris), Кристины Э. Полк
38 Благодарности

(Christine Е. Polk), Гленна Э. Сиба (Glenn Е. Sieb ), Джухани Тали (Juhani Tali)
и многих других членов Лиrи профессиональных системных администраторов
(League of Professional System Administrators - LOPSA). Отдельный привет и наи­
луч шие пожелания Майку Чейлапу (Майку Челапу) за любовь, верность и под­
держку, и особенно за горы выстиранного белья и вымытых тарелок, пока Стра­
та писала книгу. Кроме того, мы горячо обнимаем и целуем малышку Джоанну
Лир (Joanna Lear) за терпение.
Благодарим корпорацию Lumeta за разрешение на публикацию второго из­
дания.
Благодарим компанию Wingfoot за разрешение использовать ее сервер
для размещения нашей базы данных для отслеживания ошибок.
Благодарим Энн Мэри Куинт (Anne Marie Quint) за ввод данных, техническое
редактирование и множество прекрасных предложений.
И последними по очереди, но не по значению, мы хотели бы упомянуть лю­
дей, без которых бы наш успех был бы невозможен: Марка Тауба (Mark Taub),
Кэтрин Нолан (Catherine Nolan), Райну Чробак (Raina Chrobak) и Лару Уайсонг
(Lara Wysong) из издательства Addison-Wesley.

За п ерво е изд ание


Наверное, мы не сможем поблагодарить всех, кто помогал нам так или ина­
че, но попытаться стоит. Большая часть этой книги возникла под впечатлением
от книги Кернигана и Пайка Практика программирования (Kemighan and Pike, The
Practice of Programmiпg)2 и второго издания книги Джона Бентли Жемчужины прог­
раммирования (John Bentley, Programmiпg Pearls).3
Мы благодарны компаниям Global Networking and Computing (GNAC)
(GNAC), Synopsys и Eircom за разрешение использовать фотографии их инфор­
мационных центров для иллюстрации реальных примеров правильного приме­
нения принципов, о которых мы пишем.
Мы благодарны следующим людям за помощь в редактировании книги: Вале­
ри Наталь (Valerie Natale), Энн Мэри Куинт (Anne Marie Quint), Джошу Саймону
(Josh Simon) и Амаре Уилли (Amara Wi\ley).
Люди, с которыми мы познакомились на конференциях USENIX, SAGE и LISA,
оказали огромное влияние на нашу жизнь и карьеру. Мы не смогли бы написать
э�у книгу, если бы не встретили их и не получили от них так много знаний.
В работе над книгой нам помогало много людей - одни из них рассказыва­
ли поучительные истории из своей практики, другие делали обзор частей или
всей книги, третьи учили нас на протяжении нашей карьеры. Единственный
справедливый способ поблагодарить их всех - перечислить в алфавитном по­
рядке и заранее принести извинения всем, кого мы не учли: Раджив Агравала
(Rajeev Agrawala), Эл Ахо (А\ Aho), Джефф Аллен (Jeff Allen), Эрик Андерсон
(Eric Anderson), Энн Беннингер (Ann Benninger), Эрик Берглунд (Eric Berglund),
Мелисса Бинд (Melissa Binde), Стивен Браниган (Steven Branigan), Шейла

2 Русский перевод: Керниrан Б.У., Пайк Р. Практика программщювания. - М.: ИД Вильяме,


2004.
3 Русский перевод: Бентли Дж. Жемчужин ы программирования. 2-е UJдание. - СПб.: Питер,
2002.
Благодарности 39

Браун-Клинrер (Sheila Brown-Klinger), Брент Чэпмен (Brent Chapman), Билл Чес­


вик (Bill Cheswick), Jlи Дэймон (Lee Damon), Тина Дарморэй (Tina Darmohray),
Бах Туок (Дейзи) Дэвис (Bach Thuoc (Daisy) Davis), Р. Дрю Дэвис (R. Drew Davis),
Инrо Дин (Ingo Dean), Арнольд де Jleoн (Arnold de Leon), Джим Деннис (Jim
Dennis), Барбара Дийкер (Barbara Dijker), Виктор Духовны (Viktor Dukhovni),
Шель-Мари Элерс (Chelle-Marie Ehlers), Майкл Эрлинrер (Michael Erlinger), Пол
Эванс (Paul Evans), Рэми Эвард (Remy Evard), Jlукман Фэйзал (Lookman Fazal),
Роберт Фал мер (Robert Fulmer), Карсон Гаспар (Carson Gaspar), Пол Глик (Paul
Glick), Дэвид "Zonker" Гаррис (David "Zonker" Harris), Кэтрин "Сарру" Гарри­
сон (Katherine "Сарру" Harrison), Джим Хикштейн (Jim Hickstein), Сандра Ген­
ри-Стокер (Sandra Henry-Stocker), Марк Хортон (Mark Horton), Билл "Whump"
Хамфриз (Bill "Whump" Humphries), Тим Хантер (Tim Hunter), Джефф Дженсен
(Jeff Jensen), Дженнифер Джой (Jennifer Joy), Алан Джадж (Alan Judge), Кристоф
Колт (Christophe Kalt), Скот К. Кеннеди (Scott С. Kennedy), Брайан Керниrан
(Brian Kernighan), Джим Jlамберт (Jim Lambert), Элиот Jlиp (Eliot Lear), Стивен
Левин (Steven Levine), Jlec Ллойд (Les Lloyd), Ральф Jloypa (Ralph Loura), Брайан
Мак-Дональд (Bryan MacDonald), Шерри Мак-Брайд (Sherry McBride), Марк Мел­
лис (Mark Mellis), Клифф Миллер (Cliff Miller), Хэл Миллер (Hal Miller), Рут Мил­
нер (Ruth Milner), Д. Тоби Моррилл (D. ТоЬу Morrill), Джо Моррис (Joe Morris),
Тимоти Мерфи (Timothy Murphy), Рави Нарайан (Ravi Narayan), Нильс-Питер
Нельсон (Nils-Peter Nelson), Эви Немет (Evi Nemeth), Уильям Н инке (William
N inke), Кэт Окита (Cat Okita), Джим Парадис (Jim Paradis), Пат Парсrиан (Pat
Parseghian), Дэвид Партер (David Parter), Роб Пайк (Rob Pike), Хэл Померанц (На!
Pomeranz), Дэвид Пресотто (David Presotto), Даr Раймер (Doug Reimer), Томми
Рейнrолд (Tommy Reingold), Майк Ричичи (Mike Richichi), Мэттью Ф. Ринджел
(Matthew F. Ringel), Деннис Ритчи (Dennis Ritchie), Пол Д. Рориrстам пер (Paul
D. Rohrigstamper), Бен Розенrарт (Ben Rosengart), Дэвид Росс (David Ross), Пи­
тер Сэйлус (Peter Salus), Скот Шульц (Scott Schultz), Даррен Шоу (Darren Shaw),
Глени Зиб (Glenn Sieb), Карл Сиил (Karl Siil), Сисили Смит (Cicely Smith), Брайан
Стэнселл (Bryan Stansell), Хэл Штерн (Hal Stern), Джей Стайлз (Jay Stiles), Ким
Супсинкас (Кim Supsinkas), Кен Томпсон (Ken Thompson), Греr Тусар (Greg Tusar),
Ким Уоллес (Кim Wallace), The Rabblt Warren, доктор философии Джери Вайтц­
ман (Geri Weitzman), Глен Уайли (Glen Wiley), Пат Уилсон (Pat Wilson), Джим Уи­
тrофф (Jim Witthoff), Фрэнк Войчик (Frank Wojcik), Джей Йу (Jay Yu) и Элизабет
Звики (Elizabeth Zwicky).
Также блаrодарим корпорацию Lumeta и компанию Lucent Technologies/Bell
Labs за поддержку наших усилий.
Последними 11 списке, но не по значению, мы хотим поблаrодарить сотруд­
нико11 издательства Addison-Wesley, оказавших нам оrромную помощь. В особен­
ности мы признательны Карен Гетман (Karen Gettman), Мэри Харт (Mary Hart)
и Эмили Фрей (Emily Frey).
О б автор ах

Томас А. Лимонче1111и - всемирно признанный автор, лектор и системный


администратор. В течение семи лет работы в компании NYC Google был старшим
инженером по надежности (SRE) таких проектов, как Blog Search, Ganeti и внут­
ренние информационные службы предприятия. В настоящее время работает
старшим инженером по надежности в компании Stack Overflow. Свою первую
оплачиваемую работу в качестве системною администратора получил еще буду­
чи студентом Университета Дрю (Drew University) в 1987 году. С тех пор работал
как в небольших, так и в крупных компаниях, таких как AT&T/Lucent Bell Labs
и Lumeta. Помимо этой, написал книгу Тiте Management Jor System Administrators
(O'Reilly, 2005). Том не только занимается профессиональной деятельностью, но
и активно участвует в общественной жизни как в масштабах штата, так и на на­
циональном уровне. Живет в Нью-Джерси.
Кристина Дж. Хоган обладает 20-летним опытом в системном администри­
ровании и сетевых разработках от Кремниевой Долины до Италии и Швейца­
рии. Приобретала опыт, работая как в небольших стартап-компаниях, так и в
средних фирмах и глобальных корпорациях. Много лет работала как консуль­
тант по безопасности; в этой роли обслуживала компании еВау, Silicon Graphics
и SystemExperts. В 2005 году вместе с Томом получила приз USENIX LISA
Outstanding Achievement Award за первое издание этой книги. Имеет степень ба­
калавра по математике и степень магистра по информатике, закончила доктор­
антуру по аэронавигационной технике, а также имеет диплом в области юрис­
пруденции. В течение шести лет работала специалистом по аэродинамике в ко­
манде Формулы-1, а также представляла Ирландию на Шахматной Олимпиаде
1988 года. Живет в Швейцарии.
Страта Р. Чейлап многие годы была руководителем сложных IТ-проектов,
пройдя путь от менеджера проекта до технического директора. Начала карьеру
системного администратора в компаниях VAX Ultrix и Unix Unisys в 1983 году
в Массачусетсском технологическом институте (МIТ) и провела в Кремниевой
Долине годы бума интернет-компаний, создавая интернет-службы для таких
клие1пов, как компании iPlanet и Palm. В 2015 году поступила на работу в компа­
нию Google как технический руководитель проектов. Была членом оргкомитетов
конференций BayLISA и SAGE. Ее хобби - сад и новые технологии наподобие
Arduino и 20 CAD/CAM. Живет в графстве Санта-Клара, Калифорния.
Часть 1

Иннов ационные
стр атег ии
Глава 1
Как вы брать ся из ямы

Некоторые группы сисrемного администрирования борются с трудносrями. Они


проваливаются в яму и пытаются выбраться из нее. Если это похоже на вашу группу,
то эта глава вам поможет. Если это не похоже на вашу группу, вы все равно найдете
много полезной информации о том, как успешные группы осrаются успешными.
Есть две особенности, характерные для успешных систем, которые вы никогда
не найдете у неудачников. Поймите их смысл - и тогда все станет на свои места.
Эrи две характеристики практически одинаковы у всех организаций, букваль­
но у всех. Мы видели самые разные информационные системы во всем мире:
большие и маленькие, коммерческие и некоммерческие, хорошо финансируе­
мые и почти заброшенные. Одни из них насrолько велики, что их работу обес­
печивают тысячи системных администраторов, а другие настолько крошечные,
что поддерживаются специалистом по информационным технологиям, работаю­
щим только один раз в неделю. Как бы там ни было, эти два признака есть у всех
успешных систем и нет у проигравших конкурентную борьбу.
Большая часть этой книги представляет собой описание мечты - наилучшие
способы проектирования, создания и обслуживания информационной системы
и архитектуры. Сообщения, которые мы получаем от читателей, когда выходим
в Интернет или приезжаем на конференции, сводятся к следующему: "Звучит
великолепно, но что я могу сделать, если мы имеем то, что имеем?" Если мы сна­
чала не поможем вам решить ваши проблемы, то остальная часrь книги будет не
слишком полезной. Эrа глава должна помочь вам выиграть время, в котором вы
нуждаетесь для того, чтобы сделать другие вещи, описанные в этой книге.
Так каковы же эти два признака?
Прежде всего, успешные группы сисrемных администраторов умеют отслежи­
вать и организовывать выполняемую работу (WIP - work in progress). Работа
WIP состоит из запросов от клиеmов, а также всех других запланированных или
незапланированных задач, которые вы должны, хотите или обязаны выполнить.
Успешные группы всегда используют сисrему отслеживания запросов и план вы­
полнения текущих работ. Проблемные организации не делают этого, и запросы
часто теряются или забываются.
Второй признак заключается в том, что успешные группы системных админи­
страторов устранили основных пожирателей времени (time sinkholes), с кото­
рыми сталкиваются все П-группы. Пожиратель времени - это проблема, реше­
ние которой требует много времени и сrановится причиной эффекта домино по
отношению к другим проблемам. Устранение пожирателей времени - основная
задача не только потому, что это экономит время, но и потому что это предот­
вращает другую неприятность.
В области информационных технологий пожирателями времени являются
инсталляция операционной системы и процесс развертывания программного
44 Часть 1. Инновационные стратегии

обеспечения. Проблемные группы неизменно выполняют эти два процесса вруч­


ную. Этот подход не только приводит к излишним затратам времени, но и созда­
ет новые проблемы . Некоторые проблемы возникают из-за ошибок и вариаций
осуществления одних и тех же процессов, выполняемых разными людьми. Неко­
торые проблемы возникают из-за самочувствия человека, свежего в понедельник
и утомленного в пятницу.
Любая проблемная группа системных администраторов может вернуться на
успешный путь развития, приняв на вооружение следующие методы.
• Отслеживание и контроль незавершенных работ. Устаноиите про­
граммное обеспечение для автоматизированной поддержки клиентов, сис­
тему отслеживания запросов, очередь или доску Kanban.
• Автоматизируйте инсталляцию операционной системы. Запускайте
все новые машины с одинаковыми параметрами, автоматизируя инсталля­
цию и конфигурирование операционной системы и приложений.
• Внедряйте принципы CI/CD для программного обеспечения. Процесс
передачи нового программного обеспечения в производство должен быть
автоматизирован с помощью принципов DevOps, таких как непрерывная
интеграция и поставка (CI/CD - continuous integration and delivery).
Очевидно, не все читатели этой книги работают впроблемных организациях,
но если вы сразу позаботитесь о сказанном выше, то все остальное станет проще.
Оставшаяся часть этой главы содержит советы, позволяющие достичь указан­
ных двух целей. Более подробно они будут описаны позже, а пока рассматривай­
те эту главу как инструкцию по выползанию из ямы, в которой вы находитесь.

Некий парень идет по улице и падает в глубокую яму, из которой не может


выбраться.
1' Мимо идет доктор, который слышит крики: "Эй! Помогите мне выбраться!"
r, Доктор пишет рецепт, бросает его в яму и уходит.
Мимо идет священник, который тоже слышит крики: "Отец, я упал в яму. Вы
можете помочь мне?" Священник пишет молитву, бросает ее в яму и уходит.
Наконец мимо идет друг человека, упавшего в яму, и слышит крики: "Эй,
Джо, это я. Ты можешь мне помочь?" И тут друг прыгает в яму.
Наш парень говорит ему: "Ты что - дурак? Теперь мы оба сидим в яме". На
что его друг отвечает: "Ну да, только я уже был здесь прежде и знаю выход!"
Jleo Макгаррай, Западное крыло, "Noёl", сезон 2, эпизод 10

1 . 1 . О рганизация сист емы WIP


В успешных организациях всегда существует система для сбора, организации
и отслеживания запросов. Почти все организации делают это по-своему, но глав­
ное в том, что у них есть такая система и они опираются на нее.
Глава 1 . Как выбраться из ямы 45

В исследовании операций термин "выполняемая работа" используется для


описания запросов от клиентов, а также всех других задач, которые вы хотите
или обязаны выполнить, как запланированных, так и незапланированных. Тер­
мин "WIP" относится как к прямым запросам клиента, так и к задачам, которые
являются часrью проектов, к срочным запросам и уведомлениям, таким как сооб­
щения о выходах из сrроя и предупреждения от сисrемы мониторинга.
Проблемные организации в лучшем случае не организованы, а в худшем -
дезорганизованы. Запросы теряются или забываются. Клиенты не имеют воз­
можносrи узнать сосrояние своих запросов и поэтому тратят много времени на
выяснение ситуации у системных администраторов ("Ну что, готово?") или, что
еще хуже, вообще ни о чем не спрашивают и предполагают их некомпетентность.
Когда группа перегружена слишком большим объемом выполняемой работы, ее
члены впадают в панику и отдают приоритет самым скандальным заказчикам,
вместо того чтобы выбирать самую важную незавершенную работу. Некоторые
группы находятся в таком перегруженном состоянии так долго, что не знают о
существовании других возможностей.
Независимо оттого, какая стратегия используется для организации системы
WIP, она должна гарантировать, что срочные запросы будут обработаны в пер­
вую очередь, менее срочные запросы будут обязательно рассмотрены, а сигналы
тревоги вызовут немедленную реакцию и для них будут выделены необходимые
ресурсы.
Типичный срочный запрос возникает, когда клиенту необходимо восстановить
пароль. Для восстановления пароля системному администратору нужно очень
мало времени, но невыполнение этого запроса останавливает всю остальную ра­
боту клиента: клиент не может ничего делать, если не имеет возможности во­
йти в сеть. Если выполнять обслуживание запросов в порядке их поступления,
то и:щенение пароля может произойти через несколько дней. Это неразумно.
Следовательно, нам нужен механизм, гарантирующий, что такие запросы будут
получать более высокий приоритет.
Самые популярные стратегии управления выполняемой работой - система
заявок (ticket system) и Kanban. Любая из них лучше, чем отсутствие любой си­
стемы . Если вам трудно сделать выбор между ними, по умолчанию выбирайте
простую систему заявок. Людям проще приспособиться к такой системе, потому
что она реализует наиболее типичное решение. Позже вы можете внедрить до­
ску Kanban, ориентированную на выполнение проектов.

1.1.1. Системы заявок


Система заявок позволяет клиентам подавать запросы в электронном виде.
Запрос сохраняется в базе данных, где ему присваивается приоритет, назначается
исполнитель и выполняется слежение за его выполнением. По мере выполнения
запроса заявка обновляется и дополняется примечаниями и информацией. Сис­
тема также регистрирует общение между клиентом и системным администрато­
ром входе обсуждений или разъяснений.
Без такой системы выполняемая работа может быть потеряна, забыта или вы­
полнена неправильно. Клиент хочет знать состояние своего запроса, и единствен­
ный способ узнать это - обратиться к системному администратору. Это отвлека­
ет системного администратора от выполнения запроса.
46 Часть 1. Инновационные стратегии

Система заявок позволяет группе лучше распределять работу. Члены группы


могут видеть хронологию заявки, облегчая передачу заявки от одного системного
администратора другому.
Единственный системный администратор также может извлечь выгоду из ис­
пользования системы заявок, потому что она играет роль его помощника, ор­
ганизовывающего запросы. Это уменьшает нагрузку, связанную с запоминанием
запросов, определением их приоритетов и т.д. Поскольку система заявок сохра­
няет хронологию каждой выполняемой работы, вам будет проще вернуться к
проблеме и начать ее выполнение с того состояния, в котором вы ее оставили.
Менеджер группы системных администраторов может исследовать очередь
или перечислять заявки, равномерно распределяя рабочую нагрузку среди чле­
нов группы. Менеджеры могут вмешиваться в эту систему, чтобы отклонять за­
просы, выходящие за пределы возможностей группы, и идентифицировать ра­
боты, которые были остановлены или требуют внимания. Таким обра:юм, менед­
жер может активно решать проблемы, а не ждать их накопления.
Система заявок также повышает степень реальности в отношениях меж­
ду системным администратором и клиентом. Иногда клиенты чувствуют, что о
них совершенно забыли, и решают жаловаться руководству. Без системы заявок
системные администраторы испытывали бы недовольство со стороны клиентов
независимо оттого, насколько оно обосновано. В этом сценарии слово клиента
противостоит слову системного администратора.
Система заявок позволяет проверить обвинение в медлительности. Если это
правда, то с помощью хронологии заявки можно сделать обзор ситуации и ор­
ганизовать конструктивное общение. Если клиент просто проявил нетерпение,
то менеджер может объяснить ему содержание соглашения об уровне обслужи­
вания (SLA - service level agreement) и назвать ему предполагаемые сроки вы­
полнения его запроса. Нам встречались ситуации, когда клиент утверждал, что
проблема решается слишком долго, хотя подал свой запрос совсем недавно. В та­
ких случаях менеджер вежливо и изящно объяснит клиенту: "Мы не можем по­
мочь Вам, если Вы не помогаете нам помогать Вам". Системные администраторы
должны предвидеть будущее, но не могут быть телепатами.
Теперь мы должны найти способ гарантировать, что срочные запросы будут
обрабатываться в первую очередь.
Представьте, что ваш список заявок упорядочен так, что срочные запросы распо­
ложены на одном конце, а долгосрочные - на другом. Если вы реагируете только на
срочные запросы, то это понравится вашим клиентам в краткосрочной перспективе,
но вы никогда не доберетесь до выполнения долгосрочных запросов, что вызовет да­
леко идущие последствия. Если же вы реагируете только на долгосрочные запросы,
то ваши клиенты никогда не получат прямой поддержки, в которой нуждаются.
Вам нужно организовать обработку очереди с обоих концов, назначив выпол­
нение срочных и долгосрочных запросов разным людям или чередуя их меж­
ду ними. Обычно организации создают многоуровневые структуры поддержки,
в которых один уровень IТ- поддержки обрабатывает срочные запросы, а вто­
рой - долгосрочные.
Большая организация может иметь службу поддержки клиентов (первый
уровень), которая принимает все новые запросы. Она обрабатывает срочные за­
просы немедленно, а остальные запросы располагает по приоритетам и назна­
чает группе системного администрирования (второй уровень). Обычно первый
Глава 1 . Как выбраться из ям ы 47

уровень обрабатывает около 80% всех запросов; остальные запросы требуют бо­
лее глубоких и специализированных технических знаний, поэтому направляются
на второй уровень. Этот подход гарантирует, что срочные запросы будут обрабо­
таны настолько быстро, насколько требуется.
В организациях среднего размера первый и второй уровни обслуживаются од­
ной и той же командой, но на первом уровне запросы выполняются младшими
системными администраторами.
В средах, где система WIP по большей части ориентирована на выполнение
проектов и непосредственно от клиентов поступает немного запросов, группа мо­
жет л ибо выделить отдельного человека, который будет обрабатывать запросы
первого уровня, либо менять членов группы по неделям.
У единственного системного администратора возникнет особая проблема:
у него никогда не будет времени для проектирования, если клиенты будут по­
стоянно его отвлекать. Работа над проектом требует сосредоточенности на про­
тяжении многих часов. Для сочетания этой работы с обслуживанием срочных
запросов требуется специальная стратегия.
В этом случае необходимо использовать стратегию деления рабочего дня на
части: часы, посвященные клиентам, в течение которых вы обрабатываете сроч­
ные запросы и заявки, и часы, посвященные проекту. В течение часов, посвящен­
ных работе над проектом, любого визитера со срочным запросом вежливо про­
сят подать запрос, который будет обработан позже. Используйте вежливые фра­
зы: "Я работаю над важным проектом для моего босса. Не могли бы вы принять
заявку, я займусь им сегодня днем?"
Уделите первые два и последние два часа дня работе с клиентами, оставив все
оставшееся рабочее время для сосредоточенной работы над проектом. Эта стра­
тегия оправдывает себя, потому что большинство срочных запросов возникает
рано утром, когда начинается рабочий день.
Успех этой стратегии обеспечивают два фактора. Первый - помержка ру­
ководства. В идеале ваш босс оценит значение стратегии, которая дает возмож­
ность клиентам получить внимание, когда они действительно нуждаются в нем
больше всего, и при этом позволяет вам закончить важный проект. Менеджеры
могут установить правило, чтобы люди регистрировали заявки в любое время,
а персональные визиты (только в случае крайней необходимости) откладывали
на первые два и последние два часа рабочего дня.
Второй ключ к успеху состоит в том, что независимо от времени рабочего
дня вы должны делать исключение для выходов служб из строя и сверхсрочных
запросов. Должно быть очевидным, что реакция на выход из строя или другая
чрезвычайная ситуация должна иметь наивысший приоритет. К сожалению,
в этом случае все клиенты могут подавать запросы, называя их чрезвычайно важ­
ными. Разумное руководство может предотвратить это, дав письменное опреде­
ление чрезвычайной ситуации.
Сверхсрочные запросы - это запросы, которые должны быть обработаны
раньше, чем сотрудник успеет оформить его регистрацию. К ним относятся вос­
становление пароля и ответы на очень простые вопросы. Кроме того, сообщение
о сломанном принтере можно обслужить как сверхсрочное, просто попросив
клиента временно использовать другой принтер.
Это расписание должно быть ежедневным. Такая последовательность помога­
ет сохранять порядок и меньше запутывает клиентов. Не стоит думать, что кли­
енты будут помнить все изменения вашего расписания на каждый день.
48 Часть 1. Инновационные стратегии

Определения типичных чрезвычайных ситуаций


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

. • техническая проблема, приводящая к быстрой потере денег компании;

• активная утечка конфиденциальной информации клиента;


• непосредственная помеха, не позволяющая напечатать газету и погрузить

ее на машину к 4:30 (в редакции газеты).

Существует много доступных систем слежения за выполняемой работой.


К бесплатному программному обеспечению относятся Request Tracker (от ком­
пании Best Practical), Trac и OТRS. Для Windows хорошим выбором является бес­
платная система SpiceWorks.
Эrот раздел - всего лишь краткий обзор. В главе 27 мы объясним, как непо­
средственно управлять службой поддержки клиентов, а в разделе 27.10 детально
рассмотрим программное обеспечение для слежения за выполняемой работой.
Процесс правильной обработки отдельного запроса описан в главе 28.

1.1.2. Методология Kanban


Методология Kanban - это другое средство организации системы WIP. Она
предназначена для групп системных администраторов, более сильно ориентиро­
ванных на выполнение проектов. Методология Kanban обеспечивает более высо­
кую степень информированности заинтересованных лиц, не относящихся к сис­
темным администраторам, и в то же самое время уменьшает безумную нагрузку,
которую испытывают некоторые IТ-организации. Для начала рассмотрим прос­
той пример, а затем разберем более сложный.
На рис. 1 . 1 представлен пример простой доски Kanban. В отличие от системы
заявок, которая помещает выполняемые работы в единственный длинный спи­
сок, методология Kanban делит их на три списка или столбца. Столбцы исполь­
зуются следующим образом.
• Невыполненные задания (backlog): список незавершенных заданий.
• Выполняемые задания (active): пункты плана, которые выполняются
вданный момент.
• Завершенные задания (completed): выполненные пункты плана.
Все вновь поступающие задачи регистрируются и размещаются в списке не­
выполненных заданий. Задачи называют карточками (caгds), потому что изна­
чально в методологии Kanban использовались регистрационные карточки, кото­
рые нанизывались на штырьки. Каждая карточка представляет собой отдельную
единицу работы. Большие проекты разделяются на множество более мелких кар­
точек, или подзадач, которые могут быть разумно решены за одну неделю.
Глава 1 . Как выбраться из я м ы 49

ПЛАН ВЫПОЛНЯЕМЫЕ ВЫПОЛНЕННЫЕ


РАЗРАБОТКИ ЗАДАНИЯ ЗАДАНИЯ

Изучить Куп и ть
Использовать
KanЬan Кanban сти керы!

исnытаrь
1
Купить
инсrруменrы
Kanban белую
доску
1
J

Рис. 1 .1 . Простая доска КапЬап

Каждый понедельник утром группа проводит совещание, на котором каждый


член выбирает три карточки из столбца Невыполненные задания, чтобы работать
над ними в течение недели. Эти карточки перемещаются в столбец Выполняемые
задания. К пятнице все три задачи должны быть решены и карточки должны пе­
реместиться в столбец Завершенные задания. В следующий понедельник карточки
выбираются снова и процесс повторяется.
Совещание в понедельник также подразумевает ретроспективный анализ. Это
значит, что участники обсуждают, что делалось правильно или неправильно в те­
чение предыдущей недели. Все ли запланированные работы были выполнены
или они потребовали больше времени? Этот обзор делается не для того, чтобы
обвинить кого-то в том, что он не выполнил задание, а чтобы выяснить ситуацию
и улучшить положение дел. Не нужно ли точнее оценить объем работы, который
можно выполнить за неделю? Не стоит ли разделить проект на меньшие части?
В конце ретроспективного обсуждения пункты из столбца Завершенные задания
перемещаются в раздел достигнутых результатов.
Выбор трех заданий в неделю устанавливает темп, который обеспечивает
гладкое и предсказуемое движение вперед. Не все группы выбирают три зада­
юt я в неделю. Некоторые устанавливают рекомендации, что считать маленькой,
средней и большой задачей, а затем ожидают, что каждый сотрудник, возможно,
выберет одну большую и две маленькие задачи или две средние задачи и т.д.
Процесс должен быть настолько простым, насколько возможно. Люди должны
получать больше одного задания в неделю, чтобы, если выполнение одной зада­
чи зайдет в тупик, иметь возможность выполнить другую задачу. Человек не дол­
жен получать слишком много задач одновременно, потому что интеллектуаль­
ная нагрузка, которой он при этом подвергается, снижает производительность
его труда. Распределение одинакового количества задач каждую неделю делает
систему более предсказуемой и менее хаотичной. Хаос создает напряжение сре­
ди сотрудников, что также снижает производительность. Лучше корректировать
объем работы, чем изменять количество заданий, которые каждый человек полу­
чает каждую неделю.
50 Часп, 1. Инно11а1\ионные страте1·ии

Некоторые группы используют больше трех столбцов. Например, после


столбца Выполняемые задания может быть вставлен столбец Верификация, под­
разумевающий проверку :�аданий. Некоторые группы помещают новое :�адаиие
в столбец Новые задания и перемещают его в раздел Невыполненные задания после
того, как оно получит приоритет.
В дополнение к столбцам на доску можно добавип, строки. Их называют до­
рожками (swimlanes), потому что они описывают траекторию задания между
столбцами к финишной черте. Группа может имеп, дне дорожки: одну - для
проектирования, а другую - для эксплуатационных задач. Бол1,шая группа мо­
жет иметь дорожки для каждой подгруппы. Эrа конфигурация является особен­
но полезной, если в разных группах используются ра:шые стратегии. Такая ситу­
ация изображена на рис. 1 .2.

ПЛАН ВЫП ОЛНЯЕМЫЕ ВЕРИФИКАЦИЯ ВЫПОЛНЕННЫЕ


РАЗРАБОТКИ ЗАДАНИЯ ЗАДАНИЯ

Группа Linux

Группа Windows

Сетевая группа

Рис. 1 .2. Доска КапЬап, ра.Jде.ленная по командам Lin ux, Windows и сетевою проекта

Как указывалос1, ранее, должен сущестно11ат1, способ обеспечения быстрой ре­


акции на срочные запросы. Методология Kanban не была бы успешной, если бы
сотрудник, ожидающий восстановления пароля, должен был бы ждан до поне­
дельника, пока эту задачу кто-нибудь выберет.
П ростое решение заключается в том, чтобы имеп. одно задание, которое
каждую неделю получало бы метку Карточка срочного запроса (QRC - Quick
Request Card). Сотрудник, в:,явший эту карточку, будет всю неделю реагировать
на срочные запросы и другие остановки в течение недели. В :'ависимости от объе­
ма срочных запросов в вашей среде эта карточка может ока:щться единственной.
Эту роль часто называют чистильщиком (interrupt sponge), хотя мы предпочита­
ем называть такого сотрудника героем недели (этот термин предложен в книге
New Relic (Goldfuss, 201 5)).
По ряду причин методология Kanban работает лучше системы заявок.
Во-первых, подход Kanban основан на принципе протягивания (pull), а не
проталкивания (push). Система заявок - это система проталкивания. Есл и
работа выполнена, ее можно протолкнуть по системе. Для того чтобы выпол­
нит�, бол1,ше задани й, сотрудники вынуждены работать интенсивнее. Если
Глава 1 . Как выбраться из ямы 51

существует большой набор невыполненных заданий, то сотрудники вынужде­


ны больше работать, чтобы все запланированные задания были выполнены.
На практике эта система обычно терпит неудачу. Задания не могут быть вы­
полнены быстрее только потому, что мы этого хотим . Утомленные люди рабо­
тают с меньшей производительностью. Если люди испытывают повышенную
нагрузку, они, естественно, уменьшают качество своей работы, стараясь уло­
житься в заданное время. Качество и скорость можно повысить за счет автома­
тизации, но трудно выделить время для таких проектов при большом количес­
тве заданий.
Система Kanban - система протягивания. Выполняемое задание перемеща­
ется по системе так, чтобы оно было закончено не позже следующей недели.
Вы выбираете фиксированный объем работы, которая должна быть выполнена
каждую неделю, и протягиваете ее через систему. Поскольку время выполнения
задания фиксировано, люди могут сосредоточиться на том, чтобы сделать свою
работу как можно лучше за указанное время. Если руководство требует выпол­
нять в течение недели больше заданий, можно нанять больше людей, распре­
делить ресурсы, чтобы устранить узкие места, обеспечить более эффективную
работу и т.д.
Во-вторых, методология Kanban повышает прозрачность. Когда клиенты ви­
дят, на каком этапе находится их запрос по отношению к другим запросам, они
лучше понимают приоритеты ком пании. Если они не соглашаются с приори­
тетам и, они могут поднять эту проблему перед руководством. Это лучше, чем
спорить с системными администраторами, которые имеют косвенное отноше­
ние к установке приоритетов и поэтому занимают оборонительную позицию.
Это также лучше, чем вынуждать людей спрашивать, почему их запросы вы­
полняются так долго; не и мея реальной информации, они, как правило, пред­
полагают, что IТ-группа некомпетентна. Одна организация, у которой мы взяли
интервью, проводила ежемесячные встречи, на которых руководители отделов
делали обзор досок Kanban и обсуждали приоритеты. Привлекая все заинтере­
сованные стороны, они создали более тесно сотрудничающее сообщество.
Для внедрения методологии Kanban требуется очень немного средств. Многие
группы начинают с регистрационных карточек на стене или белой доски. Элек­
тронные системы Kanban улучшают регистрацию хронологии и показателей,
а также облегчают взаимодействие с удаленными сотрудниками. Существуют
коммерческие веб-системы, которые являются либо бесплатными, либо недоро­
гими, например Tгello и LeanKit. Кроме того, существуют решения с открытым
исходным кодом, такие как Taiga и KanBoaгd.
Настройте доску Kanban с учетом долгосрочных потребностей вашей группы .
Не существует идеального сочетания столбцов и дорожек, поэтому начинайте
с простого. Добавляйте и изменяйте элементы доски по мере расширения, по­
вышения зрелости и изменения состава группы.
Наше описание методологии Kanban является элементарным. Есть способы
обработки блоков заданий, пределы скорости и другие концепции управле­
ния проектом. Более полное объяснение можно найти в книгах Personal КапЬап:
Mapping Work 1 Navigating Life (Benson & Barry, 201 1) и Ka,iban: Successful Evolutionary
Change for Your Technology Business (Anderson, 2010). Для менеджеров проекта будет
полезной книга Agile Mmiagemeнt шith КапЬап (Brechner, 2015).
52 Част�, 1. Инновациою�ые стратегии

Мясорубка
Наилучший по качеству говяжий фарш можно сделать, вращая ручку мя­
сорубки с определенной скоростью и прочищая мясорубку постоянно, а не
время от времени.
Управление работой на основе принципа проталкивания ориентируется на
скорость. Для того чтобы пропустить через мясорубку больший объем мяса,
нужно чаще и больше заталкивап, в нее куски, повреждая их при этом, но
гарантируя желаемый объем на выходе. Кроме того, скорость можно повы­
сить, если не делать паузы для чистки мясорубки.
' Управление работой на основе принципа протягивания ориентируется на
качество. Каждый день через мясорубку пропускается определенный объем
мяса, не превышая заданной скорости. Этот процесс характеризуется опре­
деленным темпом. Руководство :шает, что для того, чтобы произвести боль-
.. ше фарша, необходимо использовать больше мясорубок или разрабатывать
новые методики дробления и очистки.
Служба поддержки экспертов, которая обязана обработать все запросы до
конца каждого дня, является системой проталкивания. Служба поддержки
клиентов становится системой протягивания, если принимает п запросов с
самым высоким приоритетом в неделю или определенное количество кар­
точек Kanban на человека в неделю. Другой метод предусматривает прием
определенного количества 30-минутных заданий вдень, как это сделано в
службе A pp le Genius Bar.

1.1.3. Система заявок иметодология Kanban


Система заявок и методология Kanban не являются взаимоисключающими.
Многие организации используют системы заявок для обработки запросов клиен­
тов и доски Kanban для работы над проектами. Некоторые а11томатизиро11анные
службы поддержки клиентов могут визуально отображап. один и тот же набор
запросов как заявки в очереди или карточки Kanban в столбцах. Методология
Kanban это средство оптимизации технологического процесса, которое можно
-

применить к любым процессам.

1 . 2. Устр анение пожирател ей вр ем ени


У проблемных групп всегда есть главный пожиратель времени, мешающий
им работать над большими эффективными проектами, которые могли бы устра­
нить источник проблемы. Образно говоря, они тратят много времени, вытирая
пол, и поэтому не имеют времени для замены протекающей трубы. Часто этот
пожиратель времени существует настолько долго, что группа к нему просто при­
выкает. Они перестают обращать на него внимание или считают, что проблему
решить невозможно.
Успешные IТ-организации работают на другом уровне. Они устранили глав­
ных пожирателей времени и теперь у них мало узких мест. Они регулярно иден­
тифицируют узкие места и поручают сотрудникам устранять их.
Глава 1 . Как выбраться из ямы 53

Мы можем долго обсуждать, как идентифицировать пожирателя времени ва­


шей группы, но в девяти случаях из десяти им является процесс инсталляции
и конфигурирования операционной системы. Кроме того, много времени отни­
мает процесс передачи новых выпусков программного обеспечения на производ­
ство, который часто на:iывается жизненным циклом поставки программного обе­
спечения (software delivery Jife cycle).

1.2.1. Инсталляция и настройка операционной системы


Мы недавно посетили компанию с проблемной информационной сетью. Сеть
представляла собой простую настольную среду приблизительно со ста рабочими
станциями (настольными компьютерами и ноутбуками). Несмотря на то что три
системных администратора работали примерно 50 часов в неделю, они все равно
не справлялись с потоком выполняемой работы. Источником проблемы было то
обстоятельство, что каждая рабочая станция была настроена по-своему, и это вы­
зывало цепную реакцию неурядиц.
Машина считается неисправной, если она находится в неопределенном или
нежелательном состоянии. Если каждая машина начинает работу с неопределен­
ного состояния, то она является неисправной. Ее невозможно исправить, потому
что это означало бы вернуть машину в первоначальное состояние, а мы не :шаем,
каким было ее исходное состояние или даже каким оно должно быть. Поддер­
живать парк машин, находящихся в неопределенном состоянии, - пустая затея.
Каждый настольный компьютер :iапускал операционную систему, которая
была предварительно установлена продавцом. Теоретически это было сделано,
чтобы сэкономить время. Это имело смысл, когда компания имела три настоль­
ных компьютера, но теперь их было сто. Системные администраторы теперь
обслуживали много разных версий Microsoft Windows, каждая из которых была
установлена немного иначе, чем остальные. В результате обработка запросов кли­
ентов стала отнимать вдвое больше времени, сводя к нулю эффект экономии от
предварительной установки операционной системы продавцом. Любое новое
программное обеспечение, которое было развернуто на машинах, нарушало ра­
боту одних машин, но не влияло на другие. В итоге системные администраторы
стали просто бояться устанавливать любое новое программное обеспечение.
Когда жесткий диск машины выходил из строя, то один системный админи­
стратор целый день менял диск и перезагружал операционную систему, пытаясь
угадать, какие пакеты программ должны быть установлены для клиента. После
атаки хакеров вся группа исправляла и перезагружала машины. Вся другая рабо­
та останавливалась. В результате все машины были настроены по-разному, даже
если их настраивал один и тот же человек.
Группа системных администраторов всегда работала в пожарном режи­
ме. Люди подвергалис1, стрессу и переутомлению, что делало их несчастными.
В свою очередь, их клиенты были недовольными, потому что их запросы игнори­
ровались перегруженными системными администраторами.
Возник порочный круг: ни у кого не было времени, чтобы решить большую
проблему, потому что большая проблема не давала для этого времени. Этот искус­
ственный стресс вызывал напряжение и неудовольствие, которые мешали думать
о больших проблемах, что вызывало еще больше напряжения и неудовольствия.
Разорвать этот порочный круг было трудно. Компания должна была поручить
одному системному администратору заниматься исключительно автоматизацией
54 Часть 1. Инновационные стратегии

процесса инсrалля ции операционной сисrемы. Группа не хотела лишиться одного


сотрудника, боясь, что осrавшиеся не справятся с потоком выполняемой работы. Не­
довольство клиеmов возрасrало. Требовалась смелость, чтобы принять это решение.
Оказывается, если клиенты привыкл и, что их игнорируют в течение многих
дней подряд, они готовы потерпеть еще немного.
Вскоре процесс инсталляции операционных систем был автоматизирован, ив
компанию поступил новый набор машин. Их диски были пустыми, и операци­
онные системы устанавливались повторно с одними и теми же параметрами. Эти
компьютеры были более надежными, потому что их аппаратные средства были
более новыми. Кроме того, они обеспечивали более эффективную эксплуатацию.
Наиболее важно то, что установка всех этих машин заняла часы, а не дни.
Повторная инсталляция машины после хакерской атаки теперь продолжалась
минуты. Кроме того, поскольку новая инсталляция предусматривала усrановку
антивирусного программного обеспечения, машина оставалась не зараженной.
Разработчиков, которые имели более высокую техническую подготовку, на­
учили стирать и повторно инсталлировать операционные системы их собствен­
ных машин. Теперь, вместо того чтобы ждать системного администратора, раз­
работчики могли самостоятельно справляться с такими задачами. Это привело
к изменению их технологических процессов, которые теперь включали создание
виртуальных машин по требованию для тестирования. В результате возникла
новая методология тестирования, которая улучшила их способносrь создавать
качественное программное обеспечение.
Вскоре порочный круг был разорван, и группа системных администраторов
получила больше времени для решения более важных задач. Это не устранило
всех их проблем, но большинство их проблем не могло быть решено, пока не
был устранен основной пожиратель времени.
Со временем старая смесь конфигураций исчезла, и все машины имели но­
вую, унифицированную конфигурацию. Эта однородность в большой степени
обеспечила взаимозаменяемость машин. В терминах бизнеса машины стали вза­
имозаменяемыми средствами: любой модуль можно было заменить любым дру­
гим . Клиенты извлекли выгоду из возможности легко переходить с машины на
машину. Помержка клиентов улучшилась, поскольку системные администрато­
ры сосредоточили все усилия на единственной конфигурации, вместо того чтобы
распылять свое внимание. Запросы удовлетворялись быстрее, потому что теперь
системные администраторы меньше времени тратили на отдельную уникаль­
ную машину. Новые приложения можно было устанавливать быстрее, потому
что теперь не требовалось тестирование для каждой отдельной разновидности.
В результате качество всех аспектов информационных технологий повысилось.
Неприятных сюрпризов стало меньше.
Если ваша группа страдает от пожирателей времени ивы хотите улучшить
конфигурацию операционной системы и эффективность процессов инсталля­
ции, обязательно прочитайте главу 8, особенно раздел 8.4. Вы также можете по­
лучить вдохновение, прочитав историю успеха, описанную в разделе 20.2.

1.2.2. Развертывание программного обеспечения


Следующим по важности пожирателем времени после завершения инсталля­
ции и настройки операционной системы является развертывание програм много
обеспечения.
Глава 1 . Как выбраться из ямы 55

Развертывание и обновление программного обеспечения очень напоминает


греческий миф о Сизифе, который вкатывал огромный валун на гору только для
того, чтобы увидеть, как он катится вниз, и повторял этот цикл до бесконечности.
Как только завершается развертывание новой версии программного обеспече­
ния, обязательно появляется сообщение о новом обновлении.
Настольное программное обеспечение обновляется относительно просто,
но обновление программ на многочисленных рабочих станциях, объединенных
в сеть, представляет собой более сложную проблему. К счастью, этот процесс
можно легко автоматизировать. Эта тема рассматривается в главе 7. Для сре­
ды Microsoft Windows это, как правило, означает инсталляцию служб Windows
Server Update Services (WSUS).
Обновление программного обеспечения сервера является еще более сложным
процессом. Чем больше людей обслуживает служба, тем она важнее и тем боль­
ший эффект оказывает каждое обновление. Для обнаружения и удаления всех
ошибок необходимо проводить всестороннее тестирование. Еще более сложные
процессы обновления требуются для устранения сбоев. Службу с десятью пользо­
вателями можно отключить для обновления программного обеспечения. Служба
с м иллионами пользователей должна модернизироваться на ходу. Это напоми­
нает замену шин на гоночном автомобиле во время остановки для дозаправки.
Термин жизненный цикл поставки программного обеспечения (software
delivery life cycle - SDLC) относится ко всему процессу разработки програм­
много обеспечения - от создания исходного текста через тестирование, упаковку
и бета-тестирование до инсталляции на производстве. Он требует согласованной
работы разработчиков и эксплуатационников, которая, собственно, и приве­
ла к появлению термина "DevOps" (Development and Operations - разработка
и эксплуатация). Каждая успешная итерация SDLC приводит к новому про­
граммному выпуску, переданному на производство.
В некоторых средах процесс SDLC может оказаться забавным месяцем оплош­
ностей. Однако, скорее всего, это будет адский месяц напряжения и боли. Во
многих организациях адский месяц наступает через каждые 30 дней.

Автоматизация ф аз SDLC
SDLC имеет следующие три фазы.
1. Интеграция. Компилирование программного обеспечения, выполнение
основных тестов.
2. Поставка. Создание инсталляционных пакетов, которые прошли полное
тестирование и готовы к передаче на производство, если организация при­
нимает такое решение.
3. Развертывание. Передача пакетов в испытательную или промышленную
среду.
Каждая фа:�а зависит от успешного завершения предыдущей. Каждая из них
может быть выполнена вручную, автоматизирована или выполнена смешан­
ным образом.
При непрерывной интеграции (continuous integration - CI) любое измене­
ние исходного кода запускает автоматический процесс обномения. При
56 Часть 1. Инновационные стратеrии

неирерывной поставке (continuous delivery СО) успешное завершение лю­


-

боrо из процессов непрерывной и нтеграции запускает а втоматический


процесс поставки программного обеспечения. При непрерывном разверть1-
вании (continuous deployment) успешное завершение любого из процессов
непрерывной поставки запускает процесс автоматического развертывания
программного обеспечения. Непрерывное развертывание часто использует­
ся для передачи выпусков на испытания, а не всегда сразу на производство.
Однако многие компании усовершенствовали свои процессы SDLC, так что
они могут уверенно использовать непрерывное развертывание для передачи
программного обеспечения сразу на производство.

Законченный пример устранения адского месяца описан в разделе 2.2. Мето­


дология DevOps, или быстрого выпуска, подробно описана в главе 20. Более глу­
боко управление службами в целом и методология DevOps будут рассмотрены в
томе 2 этого издания. Настоятельно рекомендуем читателям ознакомиться с кни­
гой Co11tinuous Delivery: ReliaЫe Software Releases Тhrough Build, Test, and Deployment
Automatio11 (HumЫe иFarley, 2010).

1.3. Методология DevOps


Методология DevOps ориентирована на создание максимально гладкого и ком­
фортного цикла SDLC. Высокоавтоматизированный процесс SDLC выводит компа­
нию на новый уровень надежности, позволяя ей успешно запускать новые вер­
сии программного обеспечения. Эrа надежность означает, что компания может
передавать новые выпуски на производство более часто, устраняя трение, которое
препятствует компаниям экспериментировать и пробовать новое. Эrа способность
экспериментировать делает компанию более конкурентоспособной, поскольку пе­
ред ней чаще открываются новые возможности, ошибки исчезают быстрее, а не­
большие шероховатости быстро сглаживаются. Эrо стимулирует развитие иннова­
ционной культуры.
В то же самое время этот подход облегчает жизнь системных администраторов.
После работы в среде, в которой снято напряжение, люди не хотят работать где-ни­
будь еще. Таким образом, хорошо настроенная среда DevOps не только двигает биз­
нес вперед, но и приносит выгоду сотрудникам. Как пишет Джин Ким (Gene Кim),
автор книг о методологии DevOps, "Противоположность DevOps отчаяние".
-

1.4. Методология DevOps без разработчиков


Организации, в которых нет разработчиков, тоже могут извлечь выгоду из
принципов DevOps. Они распространяются на все сложные процессы, которыми
переполнена область системного администрирования. Перечислим принципы
DevOps по порядку.
• Превращайте хаотические процессы в повторяемые и измеряемые.
Унифицированные процессы должны документироваться, а затем авто­
матизироваться. Это повышает их эффективность и уровень самообслу­
живания. Для того чтобы выполнить IТ-масштабирование, не обязательно
Глава 1 . Как выбраться из я м ы 57

решать IТ-задачи, достаточно уметь обслуживать систему, которая решает


IТ-задачи вместо нас.
• Обсуждайте задачи и проблемы внутри групп и между группами. Не
скрывайте и не замалчивайте проблемы, nытайтесь найти их решение или
тихо страдайте. Организовывайте каналы для сообщений о проблемах. Ра­
бочие процессы должны усиливать обратную связь и поощрять коммуни­
кацию между командами.
• Пробуйте новое, измеряйте результаты, запоминайте путь к успеху
и учитесь на ошибках. Создайте культуру экспериментирования и учебы
с использованием технологий, повышающих творческий потенциал, и про­
веренные методы управления, которые заслуживают изучения . Этот под­
ход называют также моделью управления "Start, Stop, Continue, Change"
("Начинайте, прекращайте, продолжайте, изменяйте"). Начните делать то,
что вы должны сделать. Прекратите делать то, что приводит к плохим ре­
зультатам. Продолжайте делать то, что приводит к хорошим результатам.
Измените то, что требует улучшения.
• Выполняйте работу небольшими порциями, чтобы иметь возмож­
ность учиться и изменять решения. Лучше поставлять результаты каж­
дый день, чем ждать и выложить все результаты в конце. Эга стратегия
дает возможность раньше установить обратную связь, выяснить проблемы
и избежать потраченных впустую усилий.
• Настраивайте диски и инфраструктуру с помощью системы управле­
ния исходным кодом. Коrда мы обрабатываем инфраструктуру как код
(IaC), она становится гибкой и тестируемой. Эго позволяет извлечь выгоду
из заимствования методик разработки программного обеспечения.
• Всегда стремитесь к лучшему. Постоянно ищите узкие места и способы
их устранения. Не ждите следующей крупной катастрофы.
• Протягивайте, а не проталкивайте. Создавайте процессы, чтобы удовлет­
ворить спрос, а не навязать предложение. Определите желательный ежене­
дельный объем результатов, распределите необходимые ресурсы и протяги­
вайте задания через систему на завершающий этап.
• Создавайте сообщество. IТ-отдел - это часть большего организма, кото­
рым является наша компания, и вы должны быть активным участником ее
успеха. В то же время мы являемся частью всемирного IТ-сообщества и обяза­
ны делиться знаниями и стимулировать профессиональное развитие.
Вы увидите принципы DevOps повсюду в этой книге, независимо от того, идет
ли речь о разработчиках. Лучшее введение в методологию DevOps - книга Тhе
Phoenix Project: А Novel About IТ, DevOps, and Helping Your Business Win (Кim, Behr &
Spafford, 2013). Мы также рекомендуем прочитать кнюу Тhе DevOps Handbook: How to
Create World-Class Agility, ReliaЬility, and Security in Technology Organizations (Кim, HumЫe,
Debois & Willis, 2016), в которой описано, как воплощать свои идеи в реальность.

1.5. Узкие места


Если и нсталляция операционной системы и развертывание программного
обеспечения не являются основными пожирателями вашего времени, то как рас­
по:шать причину потери времени?
58 Часть 1. Инновационные стратегии

Обсудите эrу тему за обедом или на совещании группы. Обычно даже корот­
кого обсуждения достаточно, чтобы выяснить основные болевые точки, причины
потери времени и снижения эффективности и т.д. Спросите мнение ваших пар­
тнеров. Они уже должны знать вашу самую большую проблему.
Более научный подход состоит в идентификации узкого места. В исследова­
нии операций узким местом (bottleneck) называют точку в системе, в которой
накапливается невыполненная работа. Приведем несколько примеров.
П редположим, что ваша группа занимается развертыванием новых персо­
нальных компьютеров. Клиенты их запросили, ив результате было куплено соот­
ветствующее аппаратное обеспечение. После их поставки на каждом компьютере
инсталлируются операционная система и программное обеспечение, и наконец
новую машину поставляют клиенrу. Если сотрудники занимают очередь в списке
ожидания, чтобы поговорить о заказе машины, то узким местом является проце­
дура заказа машины. Если клиенты неделями ждут поставки аппаратных средств,
то узким местом является процедура покупки. Если купленные машины уста­
новлены на рабочих местах и ждут инсталляции программного обеспечения, то
узким местом является процедура инсталляции.
Группа, разрабатывающая веб-приложение, состоит из членов, выполняющих
разные задания: одни пишут код, другие ero тестируют, третьи развертывают бе­
та-версию, а четвертые внедряют ее в производство. Посмотрим, что произой­
дет, если будет обнаружена ошибка. Если она остается в системе обнаружения
ошибок, никем не исправленная и никому не назначенная, тогда узким местом
является процесс рассмотрения ошибок. Если же исправление ошибки поручено
кому-то, но этот человек не решает проблему, то узким местом является этап
разработки. Если ошибочный код исправлен быстро, но не используется, потому
что не быil передан на тестирование или в производство, то узким местом явля­
ется этап испытания или развертывания.
Как только узкое место обнаружено, важно сосредоточиться на том, чтобы
устранить его. Некоторые факторы можно улучшить во всей системе, но усилия
следует направить только на оптимизацию процесса в узком месте, иначе вы не
достигнете полной производительности системы. Все оптимальные решения, от­
носящиеся к элементам системы, расположенным до узкого места, просто при­
ведут к более быстрому накоплению незавершенной работы в узком месте. Опти­
мизация элементов системы, расположенных за узким местом, просто улучшают
часть процесса.
Рассмотрим пример развертывания персональных ком пьютеров. Предполо­
жим, что узким местом является инсталляция операционной системы. Техник
может установить и настроить операционную систему на десяти машинах в не­
делю, но каждую неделю требуются больше десяти машин. В этом случае мы
увидим накопление запросов в точке, в которой выполняется инсталляция опе­
рационной системы на машине.
Создание веб-приложения для управления запросами не изменит количества
машин, устанавливаемых каждую неделю. Людям нравятся такие усовершенство­
вания, которые, на первый взгляд, расширяют систему. Возможно, им очень инте­
ресно программировать, но, к сожалению, это не изменит того факта, что каждую
неделю устанавливается только десять машин. Можно было бы нанять побольше
людей, чтобы они приносили машины в офисы, но потом им будет просто нечего
делать. Следовательно, такие усовершенствования были бы неумесrными.
Глава 1 . Как выбраться из ямы 59

Только сосредоточив усилия на узком месте, вы сможете развертывать больше


машин в неделю. В данном случае мы могли нанять больше людей или автомати­
зировать процесс. Вы можете предположить, что сделали бы авторы.
Теперь допустим, что проблема кроется в процессе покупки. Поставщик те­
ряет или путает заказы и часто поставляет неправильные типы машин. Лицо,
ответственное за покупки, тратит слишком много времени, решая эти проблемы,
которые приводят к накоплению заказов.
С одной стороны, вы могли бы сесть за стол с человеком, ответственным за
покупки, и независимым разработчиком аппаратных средств, чтобы выяснить,
почему заказы продолжают теряться. С другой стороны, существует незначитель­
ная техническая проблема, связанная с тем, что процесс инсталляции операци­
онной системы отнимает дополнительные 30 секунд. Решение этой проблемы
приносит моментальное удовлетворение и требует не больше минуты. Конечно,
мы знаем, что ни одно действие в области IТ-технологий, на самом деле не зани­
мает одну минуту. Скорее всего, на решение этой проблемы у вас уйдет полдня.
Возможно, эта половина дня будет потрачена на поиски узкого места.
Мораль этой истории заключается в том, что вы должны подавить желание
получить моментальное вознаграждение или принять поверхностное решение
и сосредоточиться непосредственно на узком месте.
Высокоэффективные группы минимизируют время на тушение пожаров.
Вместо этого они непрерывно снимают показатели своей системы, выявляют уз­
кие места и устраняют их. Незапланированная работа и чрезвычайные ситуации
должны представлять собой исключение, а не правило.

Устранение самоrо крупноrо пожир ателя времени


Работая в ком пании Cibernet, Том выяснил, что лондонская группа систем­
ных администраторов компании не достигала никакого прогресса в крити­
ческих, первоочередных проектах, потому что тонула в запросах о помощи,
касающихся работы с индивидуальными настольными персональными ком­
пьютерами.
Старшие системные администраторы был перегружены, но наем дополни­
тельного старшего системного администратора не помог бы. Ему понадо­
билось бы слишком много времени, чтобы войти в курс дела. Необходимо
было освободить время старших системных администраторов за счет отказа
от задач, которые могли быть решены кем-то другим, например справочной
службой. Технических сотрудников, которые могли бы давать справки по ра­
боте с системой Windows, множество, их зарплата невелика и они не тре­
буют большого обучения. Руководство долго не позволяло старшему адми­
нистратору нанять такого человека, но в конце концов согласилось на наем
временного сотрудника на шесть месяцев.
Благодаря этому сотруднику, решающему типичные проблемы, связанные
с настольными компьютерами (лечение от вирусов, установка новых настоль­
ных компьютеров, восстановление паролей и т.д.), остальные системные ад­
министраторы высвободили время для работы над первоочередными проек­
тами, которые были ключевыми для компании.
60 Часть I. Инновационные стратегии

К концу шестимесячного контракта руководство могло убедиться, что работа


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

1.6. Первые шаги


Мы загрузили ваши головы большим количеством прекрасных идей и превос­
ходных методов. Вы даже знаете, как идентифицировать самое важное узкое место.
Так как вы будете его устранять? С чего вы начнете? Как вы убедите своих коллег,
группу или менеджера взять любой из перечисленных методов на вооружение?
Люди часто удивляются тому, что сотрудники всегда сопротивляются переме­
нам, независимо оттого, насколько плохо работает система. Ваши коллеги могут
бояться перемен, потому что привыкли к текущему положению дел. Предложе­
ние внести изменения может показаться оскорбительным сотрудникам, созда­
вавшим систему, которую вы хотите исправить. Ваш босс, возможно, просто не
хочет, чтобы вы тратили время на какие-то проекты, кроме тушения пожаров,
которые вас наняли тушить.
Наш ответ - начинайте с малого. Не пробуйте исправить все сразу. Выберите
достижимую цель, достипште ее и повторите процесс.
• Маленькие изменения требуют меньше согласований. Большие изменения
требуют презентации PowerPoint, согласия группы и трех уровней руко­
водства. Маленькие изменения заслуживают случайного предложения, ко­
торое будет одобрено кивком головы. Выберите наименьшее приращение
работы, которое приведет к значимому изменению.
• Маленькие изменения встречают меньше сопротивления. Коллеги, равные по
положению, сопротивляются большим изменениям, которые угрожают их
статус-кво. Люди любят маленькие изменения, которые они полностью пони­
мают, и чувствуют, что можно достигнуть их и устранить болевые точки, кото­
рые затрагивают их лично (главным образом, по последней причине).
• Маленькие успехи внушают уверенность и облегчают возможность полу­
чить одобрение для следующего предложения.
• Маленькие изменения позволяют быстрее достичь результата. Лучше
устранить часть проблемы, чем получить ее полное решение позже. Выпус­
кайте версию 1 .0, которая автоматизирует один аспект задачи, так, чтобы
вся группа могла извлечь выгоду из этой автоматизации. Через неделю вы­
пускайте версию 1 .1, которая автоматизирует еще один специальный слу­
чай. Уже через неделю ваши сотрудники оценят выгоду от вашей работы.
А теперь представьте себе, что в противном случае вам пришлось бы ждать
одобрения не меньше года.
• Маленькие изменения позволяют лучше реагировать на неожиданности.
Если маленький проект будет отменен, то вы потеряете, возможно, только
один рабочий день. Оrмена большого п роекта привела бы к потере недель
или месяцев бесплодных усилий.
Глава 1 . Как выбраться из ямы 61

• Маленькие изменения привлекают сотрудников. Если вы автоматизируете ин­


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

1 . 7. Резюме
Остаток этой книги полон высоких, иногда идеалисrических идей, касающих­
ся организации работы системного админисrратора. В этой главе рассмотрены
некоторые изменения, оказывающие сильное влияние на работу сисrемы, кото­
рая тонет в проблемах.
Необходим способ управлять выполняемой работой, особенно запросами
клиентов. Клиенты - это люди, которым м ы служим (часrо называемые поль­
зователями). Использование сисrемы отслеживания запросов для управления
выполняемой работой означает, что сисrемный админисrратор тратит меньше
времени на отслеживание запросов и точнее объясняет клиентам сосrояние их
запросов. Сисrема отслеживания запросов повышает возможности системных
администраторов обрабатывать запросы клиентов. Методология Kanban это
-

альтернатива, которая больше подходит группам, работающим над проектам и,


но поддерживающим запросы клиентов с помощью специальных дорожек. Сис­
тема Kanban задает темп, которому подчиняется рабочий процесс. Она позволя­
ет оценивать прогресс и оптимизировать работу вмесrо того, чтобы прибегать к
интенсивному проталкиванию заданий.
Должен быть способ должным образом реагировать на срочные запросы, что­
бы оправдать надежды клиентов и предоставить сисrемным админисrраторам
непрерывный интервал времени для работы над проектом. Выделение отдель­
ного человека, смены или подгруппы людей для обработки запросов позволяет
другим членам группы сосредоточиться на долгосрочной работе над проектом.
Необходимо устранить самого крупного пожирателя времени. Если система
не имеет автоматизированного способа инсталляции и настройки машин, то все
другие задачи будет труднее решить. Эксплуатация машин будет затруднена,
потому что каждая машина немного отличается от другой. Будет трудно раз­
nернуть новые службы, потому что все изменения невозможно проверить. Будет
невозможно насrраивать машину, потому что мы не знаем, на что должна быть
похожа правильная машина. Автоматизируя и нсrалляцию и конфигурирование
операционных сисrем, мы запускаем все машины с одинаковыми параметрами.
Автоматизация процесса обновления программного обеспечения позволяет мас­
штабировать систему.
Другой типичный пожиратель времени - процесс развертывания программ­
ного обеспечения. Жизненный цикл программного обеспечения представляет
собой непрерывный процесс от создания исходного текста через тестирование,
упаковку и бета-версию до инсrалляции на производстве. В проблемных орга­
низациях эти этапы выполняются вручную и сrановятся всепоглощающим и бо­
лезненным процессом. Организации, которые автоматизировали непрерывный
процесс, не только избежали множесrва неприятностей, но и предоставили воз­
можносrь выпускать новые версии с повышенной надежносrью. Эта надежносrь
позволяет компаниям более активно добавлять новые функциональные возмож­
носrи и решать проблемы.
62 Часть 1. Инновационные стратегии

Методология DevOps - это ряд идей и принципов, которые применяются


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

Упражнения
1. Что такое WIP?
2. Как система заявок улучшает нашу способность прослеживать незавершен-
ные задания?
3. Как работает метод Kanban?
4. Сравните систему заявок и метод Kanban.
5. Как вы прослеживаете незавершенные задания в своей среде? Что вам нра­
вится, а чего вы не любите в этом процессе? Что вы хотели бы улучшить?
6. Как вы гарантируете, что системные администраторы вашей организации
выполняют запросы?
7. Будет ли замечено в вашей организации, если часть незавершенных зада­
ний была проигнорирована или их выполнение было остановлено? В про­
тивном случае как вы могли бы это распознать?
8. Почему важно автоматизировать инсталляцию операционных систем?
9. Перечислите операционные системы, поддерживаемые в вашей среде в
порядке популярности. Какая автоматизация используется для их инстал­
ляции? Автоматизация какого процесса могла бы принести наибольшую
пользу?
10. С помощью какого продукта можно было бы автоматизировать инсталля­
цию операционной системы?
11. Перечислите основных пожирателей времени в своей среде? Назовите два
способа их устранения.
12. Назовите самое важное узкое место в своей среде? Что можно сделать, что­
бы оптимизировать или устранить его?
Глава 2
Пр инцип малых ш агов

Одна из тем, которые мы обсудим в этой книге, - принцип малых шагов:


работу лучше выполнять маленькими шагами, чем большими скачками. Малень­
кие шаги позволяют быстрее получить результаты с более высоким качеством
и меньшим напряжением.
Эrа глава начинается с примера, который не имеет никакого отношения к сис­
темному адми нистрированию, чтобы продемонстрировать общую идею. Затем
мы рассмотрим три примера, характерных для информационных технологий,
чтобы показать, как применяется этот метод и какие выгоды он приносит.
Принцип малых шагов - часть методологии DevOps. Он заимствован у ме­
тодологии бережливого производства (Lean Manufactuгing), которое часто назы­
вают производством по принципу "точно в срок" (just-in-time - JIТ). Его можно
применить почти к любому виду процесса, который выполняется относительно
часто. Он также допускает применение методологии приложения с минималь­
ной функциональностью (minimum viaЫe pгoduct - MVP), которая подразумева­
ет запуск минимальной версии службы, чтобы получить раннюю обратную связь
и выработать проектные решения, которые будут приняты позже.

2. 1 . Аналогия с плотником
Представьте плотника, которому нужны 50 досок одинаковой длины.
Он мог бы выпилить все 50 досок, а затем измерить их, чтобы убедиться, что
все они и меют правильный размер. Было бы очень печально обнаружить,
что на десятой доске полотно сдвинулось и все доски, начиная с одиннадцатой,
теперь непригодны. Плотнику пришлось бы выпилить 40 новых досок. Как это
неприятно!
Лучше было бы проверять длину после того, как была выпилена каждая дос­
ка. Если полотно сдвинется, то плотник обнаружит проблему сразу после того,
как это случилось, и у него будет меньше отходов.
Эrи два подхода демонстрируют разницу между большими скачками и ма­
лыми шагами. В м ире больших скачков работа была бы сделана за два больших
этапа: плотник выпил ивает все доски, а затем их осматривает. В мире малых ша­
гов процесс разбивается на множество итераций: выпиливание и осмотр, выпи­
ливание и осмотр и т.д.
Одна из выгод подхода, основанного на мелких шагах, - меньший объем от­
ходов. Поскольку ошибка или дефект обнаруживается немедленно, проблема
устанавливается прежде, чем затрагивает другие доски.
Менее очевидная выгода - меньшее время простоя. На строительной площадке
есть вторая группа плотников, которые используют доски, чтобы строить дом. Дос­
ки не могут использоваться до осмотра. Если применяется первый метод, то вторая
64 Часть 1 . Инновационные стратеги и

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

2. 2 . Устранение адского месяца


В одной компании работала группа разработчиков программного обеспече­
ния, которые создавали новый выпуск каждые шесть месяцев. После завершения
поставки выпуска группа эксплуатационников останавливала все работы и внед­
ряла выпуск в производство. Этот процесс занимал три или четыре недели и был
очень напряженным для всех, кто принимал в нем участие. Планирование перио­
да обслуживания связано со сложными переговорами. Тестирование каждого
выпуска было сложным и требовало участия всех сотрудников. Реальная инстал­
ляция программного обеспечения никогда не срабатывала с первого раза. Как
только програм мное обеспечение было развернуто, обнаруживалось множество
серьезных ошибок, каждая из которых исправлялась с помощью заплаток, кото­
рые приходилось выпускать вдогонку.
Несмотря на то что процесс развертывания был трудоемким, никто не пытался
его автоматизировать. Группа внедрила много рационализаторских предложений,
которые устранили этот пробел. В интервале между выпусками промышленная
инфраструктура значительно изменялась, в результате чего каждый выпуск пре­
вращался в "движущуюся мишень". Предполагалось, что любая автоматизация
окажется бесполезной после следующего выпуска, потому что инструкции по ин­
сталляции каждого нового выпуска оказывались совершенно разными. С каждым
следующим выпуском всегда возникала более важная и острая проблема, кото­
рую нужно было решать в первую очередь. Таким образом, тех, кто действительно
хотел автоматизировать процесс, просили "подождать до завтра", но это завтра
никогда не наступало. Кроме того, каждый тайно надеялся на то, что возможно,
только возможно, следующий цикл выпуска не будет настолько плохим, как пре­
дыдущий. Такой оптимизм - это триумф надежды над опытом.
Выпуск новой версии был напряженным и болезненным месяцем для всех со­
трудников. Вскоре этот месяц стал называться адским. Что еще хуже, каждый вы­
пуск обычно запаздывал. Эrо делало невозможным предварительное планирова­
ние работы группы по эксплуатации. В частности, было трудно наметить любое
время отпуска, что еще более удручало всех сотрудников.
Сочувствуя группе, кто-то предложил выпускать новые версии менее часто,
возможно, каждые 9 или 12 месяцев. Если какая-то работа причиняет боль, то
естественно желать делать ее менее часто.
Ко всеобщему удивлению группа по эксплуатации предложила пойти в дру­
гом направлении: выпускать новые версии ежемесячно. До сих пор компания
работала большими скачками. Для того чтобы улучшить ситуацию, компания
должна была перейти на принцип малых шагов.
Люди были потрясены! Они предполагали, что теперь каждый месяц станет
адским! Однако, если какой-то процесс выполняется часто, возникает больше
стимулов его автоматизировать. Если что-то случается нечасто, то особой нужды
Глава 2. Принцип малых шагов 65

в автоматизации не возникает, и м ы отклады ваем ее в долгий ящик. Кроме того,


при ежемесячном выпуске новых версий инфраструктура изменяется меньше.
Если бы изменение инфраструктуры действительно мешало автоматизации вы­
пуска, то было бы проще обнаружить проблему.
Перемены не произошли внезапно. Сначала разработчики и зменили свою ме­
тодологию, перейдя от крупных выпусков, содержащих множество новых функ­
циональных возможностей, к маленьким итерациям, каждая из которых и мела
несколько конкретных новых функций. Это было крупным изменением, и про­
цесс убеждения в справедливости этой идеи группы и руководства был длинным .
Тем временем группа п о эксплуатации автоматизировала процессы тестиро­
вания и развертывания. Автоматизированная система могла получить последний
код, проверить его и развернуть в области бета-тестирования меньше чем за час.
Передача кода на производство все еще выполнялась вручную, но повторное ис­
пользование кода для выпуска бета-версий со временем стало требовать все мень­
ше ручной работы.
В результате область бета-версий обновлялась несколько раз в день. П оскольку
этот процесс был автоматизирован, было немного причин не делать этого. Это
сделало процесс непрерывным, а не периодическим. Каждое изменение кода за­
пускало полный пакет тестирования, и проблемы обнаруживались через мину­
ты, а не месяцы.
Передача выпусков на производство происходила ежемесячно, потому что
этот процесс требовал координации групп разработки, маркетинга, продаж,
поддержки клиента и других. При этом всем этим группам понравился переход
от ненадежного, основанного на надеждах шестимесячного графика к надежному
ежемесячному графику. Скоро эти группы выступили с инициативой выпускать
новые версии еженедельно с перспективой перехода к ежедневным выпускам.
В новом мире малых шагов были получены следующие выгоды.
• Новые функциональные возможности появляются быстрее. Есл и
в прошлом новая функциональная возможность продукта появлялась
только через шесть месяцев, то теперь от идеи до продукции проходило
всего несколько дней.
• Адский месяц был устранен. После сотен безаварийных переходов к бе­
та-версиям передача в производство стала простой, как никогда.
• Группа по эксплуатации могла сосредоточиться на более высокоприо­
ритетных проектах. Группа по эксплуатации больше не прини мала не­
посредственного участия в выпусках п рограммного обеспечения, кроме
исправления ошибок автоматизации, которые были редкими. Это высво­
бодило группу для более важных проектов.
• Стало меньше препятствий для исправления ошибок. Первый шаг
в процессе исправления ошибки состоит в идентифи кации и зменений
кода, которые ее вызвали. В ыпуск программного обеспечения через круп­
ные интервалы времени был связан с сотням и и тысячами изменений, ко­
торые необходимо было проверить, чтобы обнаружить источник ошибки.
При выпуске новых версий через короткие интервалы стало гораздо проще
обнаруживать ошибки.
• Ошибки стали исправляться быстрее. Обнаружить ошибку в коде, кото­
рый был написан шесть месяцев назад, намного труднее, чем в только что
написанном тексте. Короткие интервалы выпуска означали, что сообщения
66 Часть 1. Инновационные стратегии

об ошибках поступали вскоре после того, как код был написан, и соответ­
ствующие разработчики могли обнаружить их точнее и быстрее.
• Разработчики ста11и по11учать немед11енное удов11етворение. Шести­
месячное ожидание, чтобы увидеть результаты своих усилий, деморали:iу­
ет людей. Видеть, что код помогает людям почти сразу после написания,
очень приятно.
• Стресс ос11а611ен. Наиболее важно, что группа по эксплуатации смогла,
наконец, взяп, долгий отпуск, что требовало точного планирования, сбро­
сить напряжение и перейти к более здоровому образу жизни.
Несмотря на то что технические выгоды были значительными, деловые выго­
ды были еще более захватывающими.
• Повышение конкурентоспособности. Надежная способность добавляп
функциональные возможности и обнаруживать ошибки позволили ком­
пании более активно внедрять новые функциональные возможности и на­
страивать сущест11ующие. Клиенты обратили на это внимание, и объем
продаж повысился.
• Меньше упущенных возможностей. В прошлом группа по продажам
отклоняла много выгодных бизнес-предложений из-за неспособности ком­
пании быстро реагировать и исполь:ювать в своих интересах возникающие
возможности. Теперь компания могла выйти на рынок, о чем раньше не
могла и мечтать.
• Повыси11ась ку11ьтура автоматизации и оптимизации. Быстрые выпус­
ки лишили смысла обычные отговорки относительно автоматизации про­
цесса. Новая автоматизированная система обеспечивала согласовашюсть,
воспроизводимость и более точную проверку ошибок, а также требовала
меньше ручной работы. Кроме того, автоматизация может выполняться
в любое время, а не только тогда, когда группа по эксплуатации свободна.
Способность создавать быстрые выпуски часто называют стратегией DevOps.
В главе 20 вы увидите подобные стратегии, которые применяются к стороннему
программному обеспечению.

В нугренние и внешние циклы выпуска


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

2. 3 . Повышение эффективности
аварийного восстанов11ения
Главная инфраструктура веб-сайта Stack Overflow находится в центре обра­
ботки данных, расположенном в Н1,ю- Й орке. Если в центре обработки данных
происходит авария или отказ в обслуживании, то запускается дублирующее обо­
рудование и программное обеспечение, находящееся в Колорадо. Дубликат в Ко­
лорадо - это полноценная работоспособная копия, за исключением того, что
она находится в режиме резервирования и ждет активации.
Глава 2. Принцип малых шаrов 67

Обновления базы данных в Нью-Йорке копируются в Колорадо. Запланирован­


ное переключение на оборудование, расположенное в Колорадо, не приведет к по­
тере данных. В случае незапланированного отказа - например, в результате выхода
из строя системы энергопитания - система потеряет приемлемо малое количество
обновлений.
Процесс аварийного восстановления довольно сложен. Необходимо перейти
на другой сервер базы данных. Службы необходимо перенастроить. Это отнимает
много времени и требует навыков от четырех разных групп. Каждый раз, когда это
происходит, возникают совершенно новые проблемы, требующие специальных ре­
шений.
Другими словами, процесс аварийного восстановления сопряжен с риском.
Когда Том работал в компании Stack Oveгflow, его первая мысль была "Я наде­
юсь, что такой сбой произойдет не на моем дежурстве".
Вести автомобиль пьяным опасно, поэтому мы стараемся этого не делать. Ава­
рийное восстановление рискованно, значит, мы должны избегать этого. Правильно?
Нет, неправильно. Есть разница между поведением и процессом. Рискованное
поведение является опасным по своей природе; оно не может стать менее риско­
ванным. Вождение в пьяном виде - опасное поведение. Оно не может стать менее
опасным, его можно только избегать. Аварийное восстановление - рискованный
процесс. Его можно сделать менее рискованным, если выполнять его чаще.
Однажды в компании Stack Overflow произошел сбой, на восстановление
после которого понадобилось десять часов. Инфраструктура в Нью-Й орке стала
значительно отличаться от инфраструктуры в Колорадо. Код, который должен
был обеспечить гладкий переход, потерпел неудачу, потому что был проверен
в идеальных условиях и подвел в реальной среде. Обнаружились неожиданные
зависимости, в некоторых случаях создавая абсурдные ситуации, напоминающие
порочный круг, которые должны были быть разрешены моментально.
Это десятичасовое суровое испытание было результатом применения страте­
гии больших скачков. Поскольку отказы случались редко, возникли перекос ин­
фраструктуры, зависимости и устаревший код. Кроме того, произошло накопле­
ние невежества: новые сотрудники не и мели опыта аварийного восстановления,
а остальные потеряли практические навыки.
Для того чтобы решить эту проблему, группа решила чаще выполнять ава­
рийное восстановление. Интервал между аварийными восстановлениями зависел
от количества накопленных изменений и других факторов, которые приводили
к проблемам при аварийном восстановлении. Вместо того чтобы допускать не­
ограниченное увеличение этого интервала, группа решила сделать его коротким.
Вместо того чтобы ждать следующего реального бедствия, чтобы выполнить ава­
рийное восстановление, они стали моделировать аварии.
Концепция моделирования аварийного восстановления на работающей систе­
ме может показаться странной, но лучше обнаружить ошибки и другие пробле­
мы в управляемой ситуации, а не в чрезвычайной. Обнаружение ошибки в чрез­
вычайной ситуации, возникшей в 4 часа утра, неприятно, потому что те, кто мо­
жет ее устранить, могут быть недоступным и, а если они доступны, то, конечно,
недовольны, что их разбудили. Иначе говоря, лучше обнаружить проблему в суб­
боту в 10 часов утра, когда все бодры, доступны и сосредоточены.
Если школьники могут делать пожарные учения один раз в месяц, то, конечно,
системные администраторы могут практиковать аварийное восстановление несколь­
ко раз в год. Группа начала отрабатывать практические навыки по аварийному вос­
становлению каждые два месяца, пока процесс не был усовершенствован.
68 Часть 1. Инновационные стратегии

В ходе каждого учения возникали проблемы с кодом, документацией и про­


цедурами. Каждая проблема регистрировалась и устранялась до следующего
учения. Сначала учения длились пять часов, потом - два часа, а в конечном сче­
те они продолжались один час незаметно для пользователей.
В ходе учений были обнаружены изменения инфраструктуры, которые не были
скопированы в Колорадо, и код, который не восстанаnлиnался должным образом.
Были идеmифицированы новые службы, которые не могли nосстанавливаться без
проблем. Был выявлен процесс, который мог быn, выполнен только одним конкрет­
ным инженером. Если бы он был в отпуске или недоступен, то компания оказалась
бы в сложном положении. Он был единственным, кто мог устранить проблему.
В течение года были выявлены все эти проблемы. Код был заменен, были
разработаны более точные предварительные тесты, а пра ктические учения дали
каждому члену команды, обеспечивающей надежность информационных систем
(SRE - Site Reliabllity Engineering), возможность глубже изучить процесс аварий­
ного восстановления. В конечном счете весь процесс был упрощен и стал проще
для автоматизации. Компания Stack Overflow получила следующие выгоды.
• Меньше неожиданностей. Более частые практические учения сделали
процесс аварийного восстановления более гладким.
• Уменьшенный риск. Процедура стала более надежной, потому что в ней
стало меньше скрытых ошибок.
• Более высокая надежность. Компания получила более надежный про­
цесс, благодаря чему специальная группа смогла теперь сосредоточиться
на более важных проблемах.
• Более быстрое обнаружение ошибок. Меньший объем изменений инфра­
структуры и кода означал, что каждое практическое учение учитывало мень­
ше изменений. Ошибки стало проще идентифицировать и легче устранять.
• Менее напряженная отладка. Ошибки стали более часто исправляться
в течение рабочего дня. Вместо того чтобы искать обходные пути или воз­
можности для исправления ошибок в нерабочее nремя, когда инженеры
хотят спать, они смогли исправлять ошибки в течение дня, имея 1юзмож­
ность обсудить проблемы и обеспечить более высокое качество ремонта.
• Более высокий уровень подготовки. Практика - путь к совершенству.
Члены группы по эксплуатации предпочитают работать в обстановке, в ко­
торой можно легко получить справку. Никто из членов команды не мог
играть роль точки отказа, которая приводит к сбою всей системы.
• Улучшенная документация процесса и автоматизация. В ходе учений
группа улучшила документацию в режиме реального времени. Автомати­
зация стала проще, потому что повторение помогало группе обнаружить
то, что можно было автоматизировать, и то, что стоило бы автоматизиро­
вать в первую очередь.
• Выявление скрытых возможностей. Практические учения стали боль­
шим источником вдохновения для общей перспективы проекта и позволи­
ли радикально улучшить все операции.
• Более довольные разработчики. Вероятность быть разбуженным в неу­
рочное nремя стала меньше.
• Более довольная группа по эксплуатации. Опасение относительно ава­
рийных восстановлений снизилось. Чем больше людей прошло обучение
Глава 2. Принцип малых шагов 69

процессу аварийного восстановления, тем меньшей стала нагрузка, лежав­


шая на людях, от которых раньше зависело восстановление всей системы.
• Улучшилась моральная обстановка. Работники смогли снова планиро­
вать летние отпуска.

Принудите11ьное время простоя в компании Google


Внутреннюю службу блокировки Google называют Chubby; ее бесплатный ана­
лог с открытым кодом называется Zookeeper. Коэффициент полезной эксплуа­
тации службы Chubby был настолько идеальным, что инженеры, проектирую­
щие системы, исходили из предположения, что отказ Chubby невозможен. В ре­
:}ультате, когда служба Chubby выходила из строя, происходил каскад отказов.
Для того чтобы решить эту проблему, руководство компании Google издало
приказ, в соответствии с которым, если время простоя службы Chubby в данном
месяце равнялось нулю, ее следовало преднамеренно выключить на пять минут.
Эrо гарантировало, что код обработки ошибок будет выполняться реrулярно.
Хотя разработчиков предупредили об этом за три месяца, первый предна­
меренный выход из строя по просьбе группы был отложен. Однако с тех пор
службу Chubby каждый месяц выключают на пять минут, чтобы выполнить код
аварийного восстановления.

2. 4 . Стартуйте рано и часто


Одному IТ-отделу требовалась система мониторинга. Количество серверов
росло и достигло уровня, при котором ручное управление стало невозможным.
Из-:}а ограниченной возможности мониторинга собственной сети IТ-отдел часто
у:шавал об авариях от клиентов, а не от своих сотрудников, причем от момента
отказа до уведомления об отказе проходили часы, а иногда и дни.
Группа системного администрирования разработала крупномасштабный проект
новой системы мониторинга. Она должна была следить за всеми службами и сетя­
ми, работать на двух крупных и мощных машинах и при выявлении проблем вы­
полнять сложную процедуру, чтобы определить, кого следует уведомить об аварии.
Через шесть месяцев они еще не и мели никакой системы мониторинга. Груп­
па погрязла в бесконечных дебатах по каждому проектному решению: стратегия
контроля, способы мониторинга отдельных служб, правила ротации пейджера
и т.д. Сама стоимость аппаратных средств была настолько высокой, что требова­
ла согласования на многих уровнях.
С логической точки зрения систему мониторинга невозможно было создать, пока
не был закончен этап планирования, а он, похоже, становился бесконечным. Обсуж­
далось все больше планов, поднималось все больше вопросов. Чем дольше продол­
жалось планирование, тем менее вероятным становилось осуществление проекта.
По существу, группа столкнулась с проблемой большого скачка. Они хотели
создать совершенную систему мониторинга одним махом. Эrо нереалистично.
Группа приняла новую стратегию маленьких шагов. Вместо того чтобы соз­
давать совершенную систему, они решили построить маленькую систему, а за­
тем ее развивать. На каждом шаге они могли показать ее сотрудникам и кли­
ентам и организовать с ними обратную связь. Они, наконец, смогли получить
70 Часть 1. Инновационные стратегии

реалистичные оценки и прекратить бесконечные дебаты. Осуществляя монито­


ринг по принципу "что угодно, не важно, что" (something-anything), они могли
выявить компоненты системы, которые работали лучше всего.
Маленькие системы более гибкие и управляемые, поэтому эксперименты
над ними более простые. Одни эксперименты работали хорошо, другие - нет.
Поскольку системы были маленькими и гибкими, было просто удалить из них
ошибки.
Эrо дало группе точку поворота. Поворот (pivot) означает изменение направ­
ления на основе поступившей информации. Лучше осуществить поворот на ран­
ней стадии разработки, чем поздно понять, что создана система, которая никому
не нравится.
Компания Google назвала эту идею "стартуйте рано и часто" ("launch early
and often"). Она означает, что начи нать работу следует как можно раньше, даже
если это означает отказ от учета большинства функциональных возможностей
и возможность работы только немногих пользователей. Информация, которую
вы получите в результате ранних запусков, позволит найти более эффективное
решение и создать более качественную службу.
Кроме того, этот принцип позволяет создать эксплуатационную инфраструк­
туру уже на ранних стадиях проекта. Некоторые компании разрабатывают служ­
бу в течение года и только потом запускают ее, сообщая об этом группе по экс­
плуатации за неделю до запуска. В итоге у специалистов по эксплуатации оста­
ется мало времени, чтобы выполнить необходимые приготовления, например
создать резервные копии, разработать график дежурств и т.д. Следовательно,
такой подход порождает проблемы. В рамках стратегии "стартуйте рано и час­
то" вы получаете опыт эксплуатации уже на ранних этапах проекта и имеете
достаточно времени, чтобы сделать это правильно.

Проваливайтесь рано и часто


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

Принцип "стартуйте рано и часто" также известен как стратегия приложе­


ния с минимальной функциональностью (MVP). В соответствии с определе­
нием Эрика Риса (Eric Ries) "приложение с минимальной функциональностью -
это версия нового продукта, которая позволяет группе собрать максимальное
количество информации от клиентов с м инимальным и усилиями" (Ries, 2009).
Иначе говоря, вместо того чтобы сосредоточиться на новых функциональных
возможностях в каждом выпуске, разработчики сосредоточиваются на проверке
предположений в каждом выпуске.
Глава 2. Принцип малых шаrов 71

Группа, создающая систему мониторинга, приняла принцип "стартуйте рано


и часто". Они решили, что каждая итерация, или маленький шаг, будет длить­
ся одну неделю. В конце недели они передавали результат на бета-тестирование
и запрашивали отзывы у заинтересованных сторон.
Для того чтобы эта стратегия была работоспособной, работу следовало разде­
лить на очень маленькие порции. Следуя советам, изложенным в книге Providence:
Failure Is Always ап Option (Punyon, 2015), они назвали свой подход "Что можно
сделать к пятнице?"
Целью первой итерации был мониторинг нескольких серверов, чтобы полу­
чить обратную связь от разных заинтересованных сторон. Группа инсталлирова­
ла систему мониторинга с открытым исходным кодом на виртуальной машине.
Эго резко контрастировало с исходны м планом системы, которая должна была
быть очень масштабной. Виртуальные машины имеют меньше входной и выход­
ной информации, а также вычислительных возможностей, чем физические ма­
шины. Аппаратные средства нельзя было заказывать и поставлять еженедельно,
поэтому на первой итерации использовались виртуальные машины. Эго было
то, что можно было "сделать к пятнице".
В конце этой итерации группа не могла получить систему своей мечты, но
получала больше возможностей для мониторинга, чем раньше.
На этой итерации группа узнала, что простой протокол сетевого управления
(SNMP - Simple Network Management Protocol) был заблокирован на большин­
стве сетевоrо оборудования организации. Оказывается, группа разработчиков
должна была координировать усилия с сетевой группой при сборе данных об ис­
пользовании сети и других статистических показателей . .Лучше было узнать это
на первой итерации, чем после окончательного развертывания системы. Для того
чтобы обойти эту проблему, группа решила сосредоточиться на контроле за ве­
щами, которыми она действительно управляла, например серверами и служба­
ми. Эго дало сетевой группе время, чтобы создать и реализовать проект SNMP
безопасным и проверенным способом.
На второй и третьей итерациях группа успешно добавила больше машин
и проверила другие варианты конфигурации и функциональные возможности.
Однако на четвертой итерации группа обратила внимание, что другие систем­
ные администраторы и менеджеры не слишком интенсивно использовали систе­
му. Это их обеспокоило. Они сделали паузу, чтобы поговорить с людьми с глазу
на глаз и получить честные отзывы.
Группа узнала, что без информационной панели, отображающей историчес­
кие данные, система была не очень полезна для ее пользователей. В прошлом во
время дебатов эта проблема никогда не поднималась. Одни люди не думали, что
она является настолько важной, пока не увидели работающую систему, другие
просто предполагали, что все системы мониторинга имеют приборные панели.
Пришло время сделать поворот.
Пакет программ, который был предусмотрен резервным планом, имел очень
сложную информационную панель. Что еще более важно, ее можно было на­
страивать в соответствии с потребностями индивидуальных пользователей. Ин­
формационные панели были самостоятельными.
После многих дискуссий rруппа решила перейти на другой пакет программ.
На следующей итерации группа инсталлировала новое программное обес­
печение и создала эквивалентный набор конфигураций. Это было сделано
очен1, быстро, потому что многие работы были выполнены уже на предыдущей
72 Часть 1. Инновационные стратегии

итерации: были приняты решения, что и как контролировать, закончена работа


с сетевой группой и т.д.
На шестой итерации вся группа активно использовала новое программное
обеспечение. Менеджеры устанавливали информационные панели, чтобы ото­
бразить ключевые показатели, которые были важны для них.
Люди давали восторженные отзывы о новой системе.
И вдруг произошло нечто интересное: в суббоrу утром вышел из строя глав­
ный сервер. Система мониторинга сообщила о неисправности сетевым админи­
страторам, которые смогли устранить проблему до начала следующей рабочей
недели. В прошлом такие происшествия уже имели место, но ремонт не начи­
нался, пока системные администраторы не приходили на рабоrу в понедельник
утром, намного позже большинства других работников. Это показало руковод­
ству большое значение системы.
На седьмой итерации система мониторинга была перенесена на физические
машины, чтобы облегчить ее масштабирование. К этому времени менеджеры,
от которых зависело одобрение закупок, с энrузиазмом использовали систему;
многие из них даже стали экспертами по настройке информационных панелей.
Было решено перенести систему на физические машины, чтобы упросить мас­
штабирование и добавить дублирующий набор аппаратных средств для сайта
горячего резервирования в другом центре обработки данных.
На последующих итерациях система стала еще более ценной для организации,
поскольку группа добавила функциональные возможности, например более слож­
ный график дежурств, более тщательно контролируемые службы и т.д. Выгоды
малых шагов, которые получили системные администраторы, перечислены ниже.
• Проверка предположений позволяет избежать потраченных впустую
усилий. Способность терпеть неудачу рано и часто позволяет вовремя сде­
лать правильный выбор. Проблемы можно исправить раньше, а не позже.
• Возможность раньше получить результат создает движение. Люди
предпочитают иметь хоть какие-то функциональные возможности сегод­
ня, чем все функциональные возможности завтра. Некоторые считают,
что хоть какой-нибудь контроль лучше, чем никакой. П ротивники видят
результаты и становятся союзниками. Руководству проще одобрить что-то
конкретное, чем нечто гипотетическое.
• Экспериментировать становится проще. Часто люди испытывают эмо­
циональную привязанность к программам. Выполняя маленькие шаги, мы
можем быть более гибкими, потому что не успеваем привязаться к нашим
прошлым решениям.
• Стратегия MVP допускает моментальное вознаграждение. Группа видит
результаты своей работы быстрее. Это улучшает ее моральное состояние.
• Группа подвергается меньшему стрессу. Над группой не довлеет боль­
шой и страшный срок, она видит только постоянный поток новых функци­
ональных возможностей.
• Обсуждать большой проект - потеря времени. Большая часть ранних
дебатов касалась деталей и функциональных возможностей, которые не
имели значения или не могли быть реализованы.
Первые несколько недель были самыми трудными. Начальная конфигурация
требовала специальных навыков. Однако, как только эта работа была выполнена,
Глава 2. Принцип малых шагов 73

люди с меньшим количеством технического опыта могли самостоятельно добав­


лять правила и создавать информационные панели. Иначе говоря, если вы бе­
рете на себя инициативу и устанавливаете ориентиры, то за вами могут после­
довать другие. Это - важная особенность технического лидерства. Техническое
лидерство означает идти первым и облегчать другим путь.
Выгода использования модели MVP заключается в том, что система всегда
работает или находtпся в состояflии поставки. Система всегда приносит выгоду,
даже если не все ее функциональные возможности реализованы. Следователь­
но, если более срочные проекты отвлекают группу, то система все еще остается
пригодной к использованию. Если бы был принят изначальный план создания
крупной системы, то появление более срочного проекта, возможно, оставило бы
систему в незаконченном и нерабочем состоянии. Сделанная работа пропала бы.
Другой аспект состоит в том, что в ходе выполнения работы группа поняла,
что не все версии имели одинаковое значение. Одни версии были важными из-за
затраченного на них времени и усилий, но содержали только внутренние изме­
нения и вспомогательные функциональные возможности. В то же время другие
выпуски содержали функциональные возможности, которые были ощутимо по­
лезными для первичных пользователей системы .
Выпуски последней категории были единственным, что имело значение
для руководства при оценке прогресса. Для них важнее всего были функциональ­
ные возможности, которые имели очевидную пользу для внешних пользовате­
лей, а не членов группы.

Праздник блаrодарения
Американский Праздник благодарения подразумевает большую трапезу.
Если вы не привыкли готовить большое количество блюд для многих людей,
то это событие, происходящее один раз в год, может стать для вас источни­
ком стресса. Любые ошибки становятся публичными: все ваши родственники
увидят, что вы потерпели неудачу. Это - большой скачок.
Вы можете разделить этот скачок на маленькие шаги, пробуя готовить по но­
вым рецептам за неделю до срока, пытаясь приготовить сложные блюда
на пробу или организовав обед вскладчину. Эти методики уменьшают риск
и напряжение.

2 .5 . Резюме
Почему маленькие шаги лучше больших скачков?
Маленькие шаги в результате повышают удовлетворенность клиентов. Функ­
циональные возможности поставляются раньше. Ошибки устраняются быстрее.
Маленькие шаги уменьшают риск. Проверяя предположения, вы уменьшаете
вероятность будущего сбоя. Больше людей получают опыт, следовательно, их на­
выки улучшаются.
Маленькие шаги уменьшают потери. Они позволяют избежать бесконечных
дебатов и проявлений перфекционизма, которые задерживают группу на старте.
Тратится меньше времени на реализацию функциональных возможностей, кото­
рые никогда не будут использоваться. Когда появляются проекты, имеющие более
высокий приоритет, группа уже имеет пригодную для использования систему.
74 Часть 1. Инновационные стратегии

Маленькие шаги поощряют экспериментирование. Мы даже можем иссле­


довать новые экспериментальные идеи, некоторые из которых превращаются
в функциональные возможности, обеспечивающие конкурентное преимущество.
Мы меньше боимся неудачи, потому что легко можем отменить маленький шаг,
если эксперимент потерпит неудачу. Что еще более важно, мы узнаем кое-что,
что поможет нам делать усовершенствования в будущем.
Маленькие шаги поощряют новшества. Поскольку они стимулируют экспе­
риментирование, мы проверяем новые идеи и сохраняем только хорошие. Мы
можем рискнуть.
Мы меньше привязаны к старым программам, которые должны быть отбро­
шены. Маленькие шаги улучшают производительность. Ошибки исправляются
быстрее, процесс их обнаружения ускоряется, потому что свежий код нами еще
не забыт.
Маленькие шаги поощряют автоматизацию. Когда какой-то процесс должен
выполняться часто, оправдания для отказа от его автоматизации становятся бес­
смысленными.
Маленькие шаги приносят удовлетворение системным администраторам. Мы
получаем моментальное вознаграждение, и адский месяц исчезает. Эrо - просто
более эффективный способ работы.
Принцип малых шагов - важная часть методологии DevOps. Он применяется
независимо от того, являетесь ли вы членом группы разработчиков, занимаетесь
сглаживанием рискованных процессов, развертываете стороннее программное
обеспечение или готовите большой обед.

Упражне ния
1. В чем заключается принцип малых шагов?
2. Почему большие скачки более опасны, чем маленькие шаги?
3. Почему лучше передавать новы й программный выпуск в производство
ежемесячно, чем каждые шесть месяцев?
4. Выберите несколько программных проектов, в которых вы участвуете или
участвовали. Как часто выпускались новые версии? Сравните и противо­
поставьте способность проектов справляться с ошибками и реализовывать
новые функциональные возможности.
5. Что лучше - потерпеть неудачу и снять с производства идеально работаю­
щую законченную систему или подождать, пока она потерпит крах?
6. В чем заключается различие между поведением и процессом?
7. Почему лучше иметь маленькое усовершенствование сегодня, чем большое
через год?
8. Опишите стратегию приложения с минимальной функциональностью
(MVP). В чем его преимущество над крупным многолетним проектом?
9. Перечислите ряд примеров рискованного поведения, которые не могут
быть улучшены на практике. Почему они опасны по сути?
10. Какие большие скачки происходят в вашей среде? Опишите их подробно.
11. Выберите проект, в котором вы участвуете. Как его можно перестроить,
чтобы люди немедленно извлекли пользу вместо того, чтобы ждать завер­
шения всего проекта?
Глава 3
Д омашние животные
и крупный рогатый скот

Эrа глава посвящена вопросам повышения эффективносrи за счет минимизации


изменчивосrи. Мы сrандартизируем работу, объединяя однотипные процессы, что­
бы выполнять их одинаково. В результате мы уменьшаем изменчивосrь, упрощая
тесrирование, облегчая поддержку клиентов и уменьшая объем поддерживаемой
инфрасrруктуры. Мы масштабируем себя. Мы не можем совершенно исключить из­
менчивосrь, но чем больше процессов мы можем объединить, тем более эффектив­
ными мы можем быть. Управление осrавшейся изменчивосrью - тема следующей
главы. Пока давайте сосредоточимся на самой процедуре объединения.
Мы не можем тратить часы на специальную насrройку каждой машины, ко­
торую мы инсrаллируем. Вместо этого мы унифицируем наши машины, чтобы
обрабатывать их единообразно, насколько возможно. Аналогично мы повышаем
эффективносrь, когда решаем связанные задачи одинаково. Например, процесс
найма новых сотрудни ков обычно связан с процессом создания учетных запи­
сей и посrавки им аппаратных средсrв. Если мы будем изобретать этот процесс
для каждого нового сотрудника, то он не только затянется, но и будет выглядеть
непрофессиональным, поскольку на каждом шаге нам придется импровизиро­
вать, желая угодить новому сотруднику. Люди высоко оценивают процесс, если
он является быстрым, эффективным и хорошо выполняемым.
Трудно улучшить процесс, если никогда не повторять одно и то же. Улучше­
ние достигается благодаря повторению; практика - путь к совершенсrву. Чем
больше мы можем объединить подобные процессы, чтобы выполнять их стан­
дартным образом, тем больше практики мы получим и лучше будем работать.

3.1. Аналогия с домашними животными


и кру1rnым р огатым скотом
Машины, которыми мы управляем, варьируются от высокоспециализирован­
ных до абсолютно сrандартных. Обычно для описания этого явления используется
сравнение с домашними животными и крупным рогатым скотом. Домашние жи­
вотные - это высокоспециализированные машины, тонко настроенные с учетом
всех пожеланий клиентов, а крупный рогатый скот - это сrандаутные машины.
Авторство этой аналогии приписывается программисту из Иельского универ­
ситета Дэвиду Джелернтеру (David Gelemteг), который использовал ее для опи­
сания файловых сисrем. Джелернтер п исал: "Если у вас есть три любимые со­
баки, то вы даете и м клички. Если у вас есrь 10 тысяч голов крупного рогатого
скота, то их имена вас не интересуют" .
76 Часть 1. Инновационные стратегии

Аналогия получила популярность, когда Джошуа Маккентай (Joshua


McKenty), соучредитель компании Piston Cloud, использовал ее в своем пресс-ре­
лизе (McKenty, 2013).
С ерверы в современном центре обработки данных похожи на щен ков - они
имеют имена, и, если заболевают, жизнь останавливается, пока не выздоровеют ...

Piston Enterptise OpenStack- это система, управляющая вашими серверами, ка к


к рупным рогатым скотом: вы нумеруете их и, когда они заболевают, стреляете им
в голову, а стадо продолжает идти вперед. Семья из трех человек может заботиться
о единственном щен ке, но несколь ко ковбоев м01ут у11равлять десятками тысяч
коров, перегоняя их на большие рассrояния и попивая вис ки.

Домашнее животное - уникальное создание. Это животное, которое мы лю­


бим и о котором заботимся. Мы берем ответственность за его здоровье и благо­
получие. При этом мы эмоционально привязываемся к нему. Мы узнаем, какую
пищу оно любит, и готовим ее специально для него. Мы празднуем его дни рожде­
ния и одеваем в симпатичную одежду. Если домашнее животное заболевает, мы
грустим. Когда ему плохо, мы везем его к ветеринару и уделяем ему все свое вни­
мание, пока оно не выздоровеет. Эта индивидуализированная забота может быть
связана с большими расходами. Однако, поскольку, как правило, у людей бывает
одно или два домашних животных, расходы остаются вполне оправданными.
Аналогично машину можно сравнить с домашним животным, если она тонко
настроена и требует специальных процедур для поддержания работы.
Стадо крупного рогатого скота - это группа, состоящая из множества по­
добных животных. Если у вас есть стадо коров, то вы со всеми коровами ведете
себя одинаково. Это обеспечивает вам выгоды массового производства. Весь ро­
гатый скот получает одни и те же условия жизни, одну и ту же пищу, одно и то
же лечение, в общем, все одно и то же. Они не имеют индивидуальности, или,
по крайней мере, мы делаем вид, что ее у них нет. Мы не испытываем к ним
симпатии. Использование методик массового производства снижает затраты
на обслуживание и повышает масштабную прибыль: экономия доллара в расче­
те на одну корову может умножиться на сотни тысяч в общем итоге.
Аналогично машины можно сравнивать с крупным рогатым скотом, если они
достаточно похожи одна на друrую, чтобы управляться одинаково. Это можно
сделать на разных уровнях абстракции. Например, операционную систему мож­
но инсталлировать единообразно, даже если аппаратные средства могут вклю­
чать в себя любое количество виртуальных или физических машинных конфи­
rураций. Кроме того, машинные аппаратные средства, операционные системы
и приложения могут быть одинаковыми на всех машинах, но данные, к которым
они обращаются, могут быть разными. Это типичная ситуация для большой
фермы веб-хостинга, где единственное различие - какой определенный веб-сайт
обслуживает каждая машина.
Обычно системы, с которыми мы имеем дело, представляют собой взаимоза­
меняемые ресурсы: любой модуль можно заменить любым другим.
Похожая метафора - снежинка. Снежинка еще более уникальна, чем домаш­
нее животное. Ни одна снежинка не похожа на друrую. Вначале система может
быть похожа на любую друrую, но после настройки и модификации она в ко­
нечном счете начинает отл ичаться от остальных систем. Возможно также, что
вначале система была уникальной, и вероятность того, что она станет похожей
Глава 3. Домашние животные и к рупный рогатый скот 77

на остальные, очень невелика. Сервер-снежинка требует специальных эксплуа­


тационных процедур. Его перезагрузка требует дополнительной работы. Обнов­
ления требуют специального тестирования . Как п исал Мартин Фаулер (Martin
Fowler) (2012), "Снежинка хороша для лыжного курорта, но плоха для центра
обработки данных'' .
Сервер-снежинка создает деловой риск, потому его трудно воспроизвести.
Если возникнет сбой а ппаратных средств или программное обеспечение будет
разрушено, то будет трудно создать новую машину, которая поддерживает ту же
службу. Это также усложняет тестирование, потому что вы не можете гаранти­
ровать, что скопировали хост в свою среду тестирования. Если в продукте будет
найдена ошибка, которая не может быть воспроизведена в среде тестирования,
то ее исправление становится намного более трудным.

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

3 . 2. М асштабирование
Системы, подобные рогатому скоту, дают возможность изменять масштаб.
В типичном архитектурном шаблоне облачных вычислений балансировщик на­
грузки управляет множеством копий веб-сервера. Предположим, что каждая
машина может одновременно обслужить 500 пользователей . Если потребуется
больше вычислительной мощности, будет добавлено больше копий.
Облачные провайдеры, такие как Amazon Elastic Comp ute Cloud (Amazon
ЕС2), Google Cloud Platform и Microsoft Azure, обладают возможностями автома­
тическоrо масштабирования, благодаря которым при необходимости они могут
подключать или отключать дополнительные копии серверов. Этот вид масшта­
бирования возможен, только если машины рассматриваются как рогатый скот.
Если и нсталляция каждой новой машины требует индивидуального внимания,
то автоматическое масштабирование становится невозможным.
В таких системах нас больше не и нтересует время безотказной работы кон­
кретной машины. Если одна машина выйдет из строя, то механизм автомати­
ческого масштабирования создаст новую. Если машина сломалась, мы удаляем
ее и предоставляем механизму автоматического масштабирования выполнить
свою работу. Время безотказной работы машины было очень важным показате­
лем в 1990-х годы, но теперь м ы и:�меряем работоспособность и доступность всей
системы в целом.
78 Ч асть 1. Инновационные стратеrии

Разновидности масштабируемой архитектуры обсуждаются в разделе 1 6.6.3


и в томе 2.

3.3. Настольные компьютер ы как р огатый скот


Концепция универсальных заменяемых машин использовалась в настольных
средах задолго до того, как была изобретена аналогия с рогатым скотом и до­
машними животными. Мы уже обсуждали важность объединения конфигураций
рабочей станции в главе 1 и более подробно обсудим ее в главе 8.
Преимущества универсальных настольных компьютеров разнообразны. Поль­
зователи извлекают выгоду благодаря более качественной поддержке клиентов,
поскольку системные администраторы больше не стремятся их учить, заставляя
приспосабливаться к бесконечным изменениям. Ремонт выполняется быстрее,
потому что становится единообразным.
Сравните это со средой, в которой каждый персональный компьютер на­
строен по-своему. Исправить проблему, связанную с программным обеспечени­
ем, трудно, потому что любое изменение может нарушить что-то еще. Трудно
понять, какие программы работают, а какие нет, если неизвестно, что именно
установлено на ком пьютере. Поддержка старых операционных систем зависит
от того, найдется ли в отделе кто-нибудь, кто помнит, как работают эти операци­
онные системы.
Создание среды, в который рогатый скот - норма, находится в центре внима­
ния глав, входящих в части 11 и Ш. Вопросы унификации парка рабочих станций,
которые являются домашними животными, рассматриваются в главе 1 1 .
··:.. � --

Прив едение к общ ему знаменателю


Одним из факторов успеха устройств Apple iPad является их унификация.
Персональные компьютеры стали настолько индивидуализированными, что
их варианты просто не поддаются учету. Одним из недостатков конкурен­
ции является тот факт, что компании соревнуются, стремясь сделать свою
продукцию уникальной, непохожей на остальные. Независимые разработ­
чики аппаратного обеспечения создали множество версий и вариантов, пы­
таясь удовлетворить клиентов из разных сегментов рынка. Когда компания
Microsoft обращала внимание на новую нишу рынка, она тут же добавляла
новые функциональные возможности, соответствующие требованиям заказ­
чика, чтобы привлечь новых пользователей. В результате к 2005 году слож­
ность поддержки парка машин Windows требовала многочисленного штата
IТ-специалистов.
Устройства Apple iPad вернули нас к одной конкретной конфигурации со
специально отобранными приложениями. Однородность сделала их более
устойчивыми и согласованными, позволяя нам сосредоточиться на приложе­
ниях, а не на инфраструктуре.
Компания Apple сохраняет полный контроль над средой iPad, чтобы, если
компания когда-нибудь повторит ошибку Microsoft, ее последствия прояви­
лись бы не так б�;.1стро.
Глава 3. Домашние животные и крупный роrатый скот 79

3.4. Аппаратные средства сервера как р огатый скот


Аппаратные средства сервера и программное обеспечение в центре обработ­
ки данных - другая ситуация, в которой существуют как домашние животные,
так и рогатый скот. В некоторых компаниях каждая машина в центре обработки
данных настраивается так, чтобы точно удовлетворять потребности выполняемых
приложений. Эти машины имеют достаточный объем оперативной и дисковой
памяти, а также, возможно, даже дополнительные внешние устройства памяти
или другие аппаратные средства. Каждая машина может работать под управле­
нием разных операционных систем или их версий. Это гарантирует, что каждое
приложение настроено оптимально.
Однако эта локальная оптимальность порождает неэффективность в глобаль­
ном масштабе. Каждая машина требует специальных процедур обслуживания.
Каждая операционная система и, возможно, даже каждая версия операционной
системы требует индивидуального внимания. Обновление системы безопасности,
которое должно быть проверено на десяти версиях операционной системы, тре­
бует намного больше работы, чем проверка только на одной или двух версиях.
Этот вид затрат в конечном счете перевешивает оптимизацию, которую можно
обеспечить для индивидуальных приложений.
В результате в больших компаниях развертывание нового сервера в центре об­
работки данных часто занимает шесть месяцев или даже больше. Консультант,
работающий в одним из американских банков, как-то сообщил, что от начально­
го запроса до запуска рабочего сервера в их центре обработки данных проходит
18 месяцев. Если вы не догадывались, почему у банков такие низкие процентные
ставки и такое плохое обслуживание, то просто представьте себе, что телефонное
приложение, которое вы хотели бы установить, начнет работать только через год
после того, как вы его купили.
Сравните это со средой, в центре обработки данных которой реализована
стратегия рогатого скота. Некоторые компании устанавливают в качестве стан­
дарта два или три варианта аппаратных средств и одну или две версии опера­
ционной системы. Вы не сможете получить именно те а ппаратные средства, ко­
торые хотели, но зато вы получите их быстро. Лучшее - враг хорошего. Что вы
предпочитаете: через неделю приступить к работе с аппаратными средствами,
которые являются достаточно хорошими, или ждать год, чтобы получить именно
те аппаратные средства, о которых вы мечтали, но которые теперь устарели?

Пример: два типа аппар атных средств Google


На протяжении многих лет компания Google применяла только два типа ма­
шин. Дисковые машины обеспечивали максимальный объем дисковой памя­
ти, которая могла быть упакована в отдельную машину. Индексные машины
(они называются так, потому что на них хранится индекс поиска) обладали
максимальным объемом оперативной памяти, который только можно было
установить в сервер типоразмером lU. Группы, которые запрашивали маши­
ны в центре обработки данных, могли выбирать машины одного или другого
типа и получать их в течение нескольких минут, потому что они были заранее
загружены и готовы к работе.
Такая организация позволяла проще обрабатывать будущие заказы. Отдел
закупок собирал заказы от всех групп и согласовывал количество требуемых
80 Часть 1. И нновационные стратегии

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


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

Не каждую среду можно свести к одному типу машин, но можно обеспечить


несколько стандартных конфиrураций (маленькую, среднюю и большую) и ори­
ентироваться на них. Мы можем минимизировать количество поставщиков, что­
бы в организации был один процесс обновления программного обеспечения,
один технологический процесс ремонта и т.д.
Фиксация размеров виртуальных машин позволяет стандартизировать вычис­
лительную мощность. Например, мы можем фиксировать размер виртуальной
машины по умолчанию, чтобы восемь виртуальных машин точно соответствова­
ли одной физической машине. Более высокую вычислительную мощность мож­
но обеспечить, умножив размер виртуальной машины, заданный по умолчанию,
на указанное число. Эго означает, что мы никогда не получим физическую ма­
шину, у которой будет неиспользованная вычислительная мощность, слишком
маленькая для того, чтобы выделить для нее новую машину. Эго также облегчает
возможность планирования будущей вычислительной мощности и реорганиза­
ции развертывания существующих виртуальных машин в пределах кластера.
Предлагая стандартизированные размеры, мы больше не рассматриваем ма­
шины по-отдельности; вместо этого рассматриваем их как единицы масштаби­
рования, с помощью которых определяется размер новой системы. Эго больше
соответствует принципам проектирования распределенных вычислительных
приложений и большинства будущих приложений.
Глава З. Домашние животные и крупный рогатый скот 81

Стандартизацию можно распространить и на программное обеспечение. Ка­


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

Влияние значений, задаШIЫХ по умолчанию


Значения, заданные по умолчанию, считаются оптимальными. Если вы пред­
ложите всем подгруппам П-специалистов изменить конфигурацию опера­
ционной системы, то услышите много неприятных слов от наиболее крикли­
вых коллег. Вам не позволят принять активное участие в этом процессе. Or
вас могут потребовать отозвать свое предложение. Часто тирания нескольких
крикливых сотрудников мешает большинству внедрять выгодные изменения.
Напротив, если вы самостоятельно измените конфигурацию всех новых сер­
веров (благодаря автоматизированной инсталляции операционной систе­
мы), то, возможно, удивитесь, насколько слабой будет реакция других со­
трудников. Большинство людей спокойно воспримуr эти изменения. Люди,
которые могли бы поднять шум, все равно будуr жаловаться, но теперь вы
сможете работать вместе с ними, решая их проблемы (см. соответствующую
историю в разделе 7.3.1).

3.5. Состояние домашних животных


Другой способ описания домашних животных - указать, что у них есть много
невоспроизводимых состояний. Крупный рогатый скот не имеет состояний или
имеет только одно воспроизводимое состояние.
Состояние - это, по существу, данные или информация. Этой информацией
могут быть файлы данных, конфигурация или статус. Например, при запуске
программы MS Excel текущая загруженная таблица представляет собой состоя­
ние. В видеоигре позиция и статус игрока являются состоянием. В веб-приложе­
нии существуют само приложение и база данных, которая используется для хра­
нения данных пользователя. Эга база данных представляет собой состояние.
Чем больше состояний хранит машина, тем более незаменимой она является,
т.е. тем больше похожа на домашнее животное. Крупный рогатый скот являет­
ся унифицированным, потому что мы можем легко восстановить его благодаря
тому факту, что у скота нет никакого состояния или только одно состояние, кото­
рое можно скопировать из другого места.
Веб-сервер, отображающий статический контент (веб-страницы и изображе­
ния), не имеет состояния, если этот статический контент является копией основ­
ного источника, сохраненного в другом месте. Веб-сервер можно стереть и пере­
загрузить, но до тех пор, пока контент можно скопировать из основного источни­
ка, новый сервер функционально совпадает с оригиналом.
Однако предположим, что веб-приложение имеет базу данных. Если маши­
на будет стерта и перезагружена, то база данных будет потеряна. Мы можем
82 Часть 1. Инновационные стратегии

восстановить ее из резервных копий, но тогда мы потеряем все новые данные, на­


копленные с моме1па последнего резервного копирования. Это веб-приложение
и меет состояние.
Конфигурационные данные также являются состояниями, но обычно их мож­
но восстановить. Информация о том, какие пакеты программного обеспечения
были установлены и как они были сконфигурированы - это состояние, даже
если содержимое самих пакетов программного обеспечения не является состоя­
нием; они поступают из главного репозитория. Состояние можно воспроизвести
вручную или с помощ1,ю автоматизации.
Невоспроизводимое состояние конфигурации может быть особенно ковар­
ным. В этом случае состояние является не конкретным файлом конфигурации,
а скорее информацией о том, как была со:Jдана система, которая делает его сер­
вером-снежинкой. Мы видели важные серверы, которые можно восстановить
только путем установки старой версии программного обеспечения и инсталля­
ции пакета обновления. Установка окончательной версии напрямую не работала.
Во время процесса обновления генерировалось неизвестное и неидентифицируе­
мое состояние, которое почему-то не воспроизводилось с помощью прямой уста­
новки. Это такое необ-ьяснимое состояние, из-за которого хочется плакать.

НевоспроизвоАимые ноутбуки
Когда Том поступил на работу в компанию Cibeгnet, она :iависела от прило­
жения, которое было установлено на множестве ноутбуков много лет назад.
К тому времени никто из работающих там сотрудников не мог понять, какая
комбинация версии Windows, заплаток и инсталляционных пакетов может
обеспечить работоспособность программного обеспечения на новом ноутбу­
ке. Каждый раз, когда один из оригинальных ноутбуков выходил из строя,
компания оказывалась на один шаг ближе к банкротству.
Ком пания разрабатывала замену для программного обеспечения. Если бы
новое программное обеспечение оказалось готовым до того, как послед­
ний ноутбук выйдет из строя, то компания выжила бы. В противном слу­
чае компания буквально не смогла бы обработать финансовую информации
для клиентов. Ей пришлось бы выйти из бизнеса. Один из ноутбуков хра­
нился в сейфе в качестве меры предосторожности. Остальные использовали
осторожно и только при необходимости.
Когда осталось всего четыре рабочих ноутбука, компания VMwaгe предста­
вила продукт, который делал снимок физического жесткого диска и создавал
образ виртуальной машины (физический или виртуальный, или p2v). К счас­
тью, это сработало, и вскоре виртуальный ноутбук можно было запустить
на любой другой машине. Это снизило риск, связанный с задержкой проекта
по замене программного обеспечения и, вероятно, спасло компанию.

3.6. Изоляция состояния


Мы можем превратить домашних животных в рогатый скот, изолируя состо­
яние. Желательно это делать в процессе проектирования, 110 иногда м ы делаем
это постфактум.
Глава 3. Домашние животные и крупный рогатый скот 83

Представьте себе типичное веб-приложение, полностью работающее только


на одном компьютере. Машина включает в себя НТГР-сервер Apache, приклад­
ное программное обеспечение, сервер базы данных MariaDB и информацию,
хранящуюся в базе данных. Эrа архитектура используется многочисленными не­
бол1.шими веб-приложениями.
Недостаток этой архитектуры заключается в том, что на одной машине хра­
нится и программное обеспечение, и состояние. Эrо домашнее животное. Соот­
ветстнующая ситуация изображена на рис. 3.1, а.

База
а) Веб-сервер
данных

6)
�1 J1
База
данных
• � р

11118111 Н е имеет состояния

GJ- �
Служба
в) базы
р
данных

1•-• Н е и меет состояния

Рис. 3 . 1 . Ра.1работка веб-служб1>1 для юоляц и и состоя ния

Мы можем улучшип. ситуацию, отделив нашу базу данных. Как показа­


но на рис. 3.1, б, мы можем перенести программное обеспечение базы данных
MariaDB и данные, которые она хранит, 11а дру�ую машину. Веб-сервер теперь по­
хож на крупный рогатый скот, потому что его можно легко воспроизвести, просто
устанонив программное обеспечение и настроив его, чтобы указать на базу данных,
хранящуюся на другом компьютере. Машина с базой данных - это домашнее жи­
вотное. Однако ситуация, в которой участвуют крупный рогатый скот и домашнее
животное, все же лучше, чем ситуация с одним крупным домашним животным.
Если сервер-скот выйдет из строя, мы легко можем его заменить. Поскольку до­
машнее животное имеет одну функцию, его проще скопировать, чтобы пригото­
виться к чрезвычайной ситуации. Мы также можем заблокировать пользователей,
поэтому вероятност1. возникновения проблем с людьми снижается, и мы можем
испол�.зовать более надежное (и более дорогое) оборудование. Определяя и изо­
лируя состояние, мы помещаем все яйца в одну корзину, но мы можем сделать ее
очень хорошей корзиной, которой мы уделяем особое внимание.
Остающееся состояние - это информация, хранящаяся в базе данных. Эти
данные можно перенести во внешнее хранилище, чтобы изолировать состояние.
Например, вместо хранения данных на локальном диске можно распределить
84 Часп, 1. Иннонаrщонн ые стратеr·и и

объем данных на нашем сервере сети хранения данных (SAN - storage area
network), как показано на рис. 3.1, в. Теперь машина ба:iы данных не имеет со­
стояния. Ее можно стереть и перезаrру:шть без потери данных. Она просто скон­
фиrурирована для подключения к пра11ильному серверу SAN, чтобы получить
ДОС1)'П К СОСТО Я НИ Ю .
Многие системы проходят подобный путь эволюции. Иногда эти изменения
происходят на этапе проектирования и в результате возникает проект, который
изолирует состояние или минимизирует количество мест, в которых хранится
состояние. Напри мер, мы могли бы консолидировать состояние в одной базе
данных вместо того, чтобы хранить какую-то информацию в базе данных SQL,
какую-то - в локальных файлах, а какую-то - во внешней службе приложений.
В друrих случаях эволюция происходит постфактум. Зачастую системные адми­
нистраторы тратят много времени на переконфиrурирование и реинжиниринr
старых систем, чтобы развивать их по мере необходимости, потому что они были
разработаны предшественниками, не читавшими эту книrу. Вам повезло.
Этот процесс также называется декомпозицией состояния (decoupling state).
Конструкция "все в одном" тесно связывает приложение с данными. Декомпо­
зиция полностыо отделяет данные от программного обеспечения. Она позволя­
ет лучше масштабировап, службу. Например, веб-сервер можно реплицировать
для увеличения вычислительной мощности.
Декомпозиция состояния упрощает масштабирование систем. Многие ме­
тоды масштабирования включают в себя репликацию служб и разделение на­
грузки между этими репликами. При проектировании системы, как правило,
легче реплицировать компоненты, не имеющие состояния. Если мы управляем
этими компонентами как крупным рогатым скотом, то можем легко генериро­
вать и уничтожать их по мере увеличения и умеш,шения спроса. Рис. 3.2 похож
на рис. 3.1, в, :ia исключением того, что компонент веб-сервера был реплицирован
для масштабиро11ания производительности интерфейсной части. В систему была
добавлена кеш-памяп, реплицированной базы, чтобы 11ыгрузить в нее запросы
на чтение, что улучшило производительность базы данных. Такого рода масшта­
бирование обсуждается далее, в главе 18.

Запро с ы
НТТР

Служба
i
базы Веб­
данных Кеш баз ы ....+ сервер
дан н ых
тоnько
дnя чтения

�··••piiii� Не имеет состояния

Рис. 3.2. Масш табирован ная служба веб-пр11,\ожен11я


Глава 3. Домашние животные и к рупный роrатый скот 85

Блоги и состояние
Состояние также можно перенести во внешние службы. Первоначально
платформы для блоrов состояли из программного обеспечения, которое ге­
нерировало каждую страницу по требованию путем чтения данных из ло­
кально сохраненных файлов и базы данных SQL. Это означало, что состояние
хранилось в трех местах - в программном обеспечении, на SQL-cepвepe и в
локальных файлах. Масштабировать такие системы очень сложно.
В 2016 году появилось новое поколение платформ для блоrов, для которых
не требовалось хранить состояние на серверной стороне. В этом случае сайт
представлял собой набор статических файлов, которые можно было загру­
жать на любой веб-сервер, даже без базы данных или с возможностью выпол­
нения кода. Такие платформы использовали клиентский сценарий JavaScript
для всех интерактивных функций.
Генераторы сайта для блогов, такие как Hugo и Jekyll, обычно работают сле­
дующим образом. Владелец блога создает репозиторий файлов Git, который
хранит все, что связано с сайтом: изображения, текст сообщений в блоге,
метаданные, описывающие, как должен выглядеть веб-сайт, и т.д. Генератор
сайта использует эту информацию для создания всего сайта в виде набора
статических файлов. Эти файлы загружаются на веб-сервер. Если в репозито­
рии Git создается новая запись в блоге, весь сайт генерируется заново и снова
загружается на веб-у:�ел.
Контент с часто изменяющимся состоянием, например комментарии поль­
зователей, обрабатывается внешними службам и, такими как Disqus. Хотя
комментарии должны динамически обновляться на сайте, на самом деле они
загружаются с серверов Disqus с использованием кода HTML5, который не
изменяется. Это устраняет большую часть инфраструктурьt, которую должен
померживать владелец блога.
Поскольку файлы являются статическими и не требуют хранения состояния
на серверной стороне, их можно обслуживать практически из любого мес­
та. К таким местам относится каталог на файловом сервере, учетная запись
Dropbox или массивная многосерверная инфраструктура веб-хостинга.

3.7. Общие пр оцессы


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

И наоборот, некоторые компании используют унифицированны й процесс


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

Прием на р аботу
Прием на работу (onboaгding) - это процесс, посредством которого новый
сотрудник принимается в компанию. Хотя обычно это не входит в компетен­
цию IТ-отдела, значительная часть процесса подразумевает использование
информационных технологий: создание учетных записей, предоставление
сотруднику компьютера, телефона и других устройств и т.д. (см. главу 12).

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


на производстве. В крупных компаниях часто используются сотни внутренних
и внешних приложений. Например, розничная компания Taгget использует ты­
сячи приложений - от управления запасами до доставки и от логистики до про­
гнозирования электронного обмена данными (EDI) и программного обеспечения,
которое обрабатывает удивительно сложную задачу создания ценников.
Во м ногих организациях каждое такое приложение создано с использовани­
ем различных технологий программного обеспечения, языков и каркасов. Одни
из них написаны на языке Java, другие - на Go, Python или РНР. Для одного
требуется определенная веб-структура, а для другого - определенная версия
операционной системы. Для одного требуется определенный набор изменений
операционной системы, а другая на машине с таким набором изменений рабо­
тать не будет. Одни поставляются как пакет инсталляции, а другие разработчик
отправляет системным администраторам как файл по электронной почте.
В результате процесс развертывания этих приложений в производстве стано­
вится очень сложным. Каждый новый выпуск программного обеспечения требу­
ет, чтобы группа по эксплуатации выполняла уникальный или индивидуальный
процесс. В некоторых случаях этот процесс каждый раз полон новых и ра:шоо­
бразных неожиданностей, часто в зависимости от того, какой разработчик руко­
водил этой конкретной версией. Джо отправляет ZIР-файлы, а Мэри отправляет
RАR-файлы. Каждый вариант требует дополнительной работы и дополнитель­
ных знаний, а также повышает сложность и риск для производства. Каждый ва­
риант затрудняет автоматизацию.
Иначе говоря, каждый из этих процессов является домашним животным.
Итак, как мы можем превратить их в скот?
В 2012 году ряд организаций определил необходимость унификации этих
процессов. Появилось м ного новых технологий, одной и:� которых был формат
Dockeг Container. Эrо формат распространения программного обеспечения, кото­
рый также унифицирует способ развертывания приложений в производственных
Глава 3 . Домашние животные и к рупный рогатый скот 87

средах. Этот формат включает не только все файлы, необходимые для приложе­
ния или службы, но и стандартный способ подключения и управления ими. Фор­
мат Docker Containers содержит метаинформацию, такую как порт ТСР, на кото­
ром работает служба. В результате в среде хост-служб практически все приложе­
ш1я моrут быть развернуты одинаково. Хотя не все приложения моrут работать
в системе Docker Container, это может значительно сократить количество домаш­
них животных в производственной среде.
Система Docker состоит из ряда элементов. Образ Docker Container это ар­ -

хивный файл (например, ZIP или TAR), содержащий все файлы, необходимые
для конкретной службы. Dockerfile это файл, описывающий, как построить
-

изображение в автоматическом режиме, тем самым обеспечив повторяемость


процесса создания изображений. Файл компоновки Docker определяет сложное
приложение, состоящее из множества контейнеров, и описывает, как они взаи­
модействуют.
/lистинr 3.1 это файл Dockerfi\e, в котором описывается создание обра­
-

за, включающего НТТР-сервер Apache и связанные с ним файлы. Инструкция


EXPOSE 8 О указывает, что программное обеспечение, в котором работает этот
образ, нуждается в эксклюзивном доступе к ТСР-порту 80.

Листи нг 3.1. Файл Dockerfile, описьmающий создан ие образа Docker


FROM ubuntu : 12 . 04

RUN apt - ge t upda t e & & apt -get i ns t a l l -у apa che2 \


& & apt - ge t clean & & rm - r f /va r / l i Ь / apt / l i s t s / *

ENV АРАСНЕ RUN U SE R www -data


ENV APACHE-RUN-GROUP www -data
ENV APACHE-LOG-D I R / va r / log / apache2

EXPOSE 80

CMD ["/ u s r / s b l n / apache 2 " , "-D" , " FOREGROUND "]

В листинге 3.2 показан файл компоновки Docker для приложения, состоящего


из двух служб: одна из них предоставляет веб-приложение, а другая - интер­
фейс API. Обе службы требуют доступа к базе данных MySQL и кешу Redis.

Л истинг 3.2. Файл Docker (.\ЛЯ: простого приложения


s e r v i ce s :
web :
g i t u r l : g i t @ g i thub . com : examp l e / node -j s - s ampl e . g i t
g i t-b ranch : t e s t
comffia nd : rac kup -р 3 0 0 0
bui ld command : rake db : mi g rate
deploy command : r a ke db : mi g rate
l og folde r : /us r / s r c / app/ log
ports : [ " 3 0 0 0 : 8 0 : 4 4 3 " , " 4 0 0 0 " ]
volumes : [ " / tmp : / tmp/mnt folder " ]
h e a l t h : defaul t
api :
image : qua y . i o / example /node
command : node t e s t . j s
port s : [ " 1 3 3 7 : 8 0 8 0 " ]
88 Часть 1. Инновационные стратегии

requi res : [ "web " ]


databa s e s :
- "mysql "
- " redi s "

В стандартизованном формате контейнера все приложения моrут доставляться


в производство в форме, настолько автономной, что IТ-отделу не понадобят­
ся тдельные процедуры для каждого приложения. Несмотря на то что каждое
по своему содержанию приложение сильно отличается от других, процесс раз­
вертывания, запуска и остановки приложения остается одинаковым.
Контейнеры можно использовать для создания бета-среды. В идеальном слу­
чае тестовая среда будет максимально похожей на рабочую. Каждый раз, когда
в процессе производства обнаруживается ошибка, она должна быть воспроизве­
дена в тестовой среде, которая будет исследована и исправлена. Иногда ошибку
нельзя воспроизвести подобным образом, и тогда ее исправление становится на­
много сложнее.
Реальность такова, что в большинстве компаний бета-версии и производствен­
ные среды сильно отличаются одна от другой: каждая из них создается отдельной
группой людей (разработчиками и системными администраторами) в собствен­
ных целях. Мы постоянно слышим о том, что разработчики, начавшие проект,
написали код, который развертывается в бета-среде. В то время системные адми­
нистраторы не участвовали в проекте. Когда пришло время для развертывания
приложения в производство, системные администраторы сделали это вручную,
потому что код развертывания для бета-среды был непригоден. Позднее, ког­
да системные администраторы автоматизировали свой процесс, они написали
код на другом языке и сделали его специфичным для производственной среды.
Теперь померживаются две базы кода, и изменения в процессе должны быть
реализованы в коде дважды. Скорее всего, изменения скрытно повлияют на код
бета-развертывания и никто этого не поймет, пока не сорвется следующее раз­
вертывание приложения на производстве. Эго выглядит как нелепые действия
глупой компании, которая является исключением, но именно так работает
огромное количество команд.
Контейнеры не только унифицируют производственную среду и делают ее
более похожей на крупный рогатый скот, но и повышают производительность
работы разработчиков. Выбирая правильную комбинацию контейнеров, раз­
работчики моrут создавать песочницы на своих личных рабочих станциях. Они
моrут создать мини-версию рабочей среды, которую они моrут использовать
для разработки. Лучше иметь все это на своих ноутбуках, чем совместно исполь­
зовать централизованно управляемую среду тестирования и ждать своей очереди
для работы с ней.
В июне 2015 года была создана инициатива Open Container Initiative (OCI), на­
правленная на создание единого отраслевого стандарта для форматов контейне­
ров и времени выполнения. Компания Docker, Inc., предоставила свой формат
контейнера и время выполнения, чтобы заложить основы для этих усилий.
Использование контейнеров - это лишь один из многих способов унифика­
ции этого процесса.
Глава 3. Домашние животные и к рупный рогатый скот 89

Контейнеры для перевозки


Концепция Docker Containers берет свое начало в судоходной отрасли. До
появления контейнеров отдельные предметы загружались и выгружались,
' как правило, вручную. Каждый элемент имел разные размеры и поэтому
должен был обрабатываться по-разному. Хрустальную люстру нужно было
тщательно перенести, в то время как большой мешок пшеницы можно было
просто бросить.
Все изменилось в апреле 1956 года, когда компания Malcom McLeans органи­
зовала первую отгрузку с использованием стандартных контейнеров.
Стандартизированные грузовые контейнеры революционизировали способ,
·· которым продукты перемещаются по всему миру. Поскольку каждый транс­
портный контейнер имел одинаковую форму и размер, загрузка и выгруз­
ка могли выполняться намного быстрее. Краны и автоматика должны были
..
быть сконструированы для обработки только одной формы со стандартизо-
ванным максимальным весом и местами подъема.
В одном контейнере хранилось много отдельных предметов, все с одина­
ковым пунктом назначения. Таможенники моrут проверять все п редметы
в конкретном контейнере и запечатывать их, устраняя необходимость в про­
ведении таможенных проверок в транзитных пунктах, если печать остается
неповрежденной.
, . Появились перевозки с использованием разного вида транспорта. Контейнер
можно было загрузить на заводе, и он оставался неизменным и на грузовике,
и на поезде, и на судне. Стандартные контейнеры для доставки принимаются
везде.

3.8. Откладывани е изменений до конца пр оцесса


Исследование операций рекомендует откладывать вариации процесса до кон­
ца. Повара ресторанов Burger Кing делают стандартный гамбургер, лишь в по­
следнюю минуту добавляя в него начинку, такую как кетчуп, горчица и соленые
огурцы. Нераспроданные запасы должны быть стандартными, чтобы их можно
было использовать при поступлении заказа. В противном случае в ресторане мо­
жет оказаться избыток нераспроданных булочек с солеными огурцами, в то вре­
мя как Кристина ждет, когда ее заказ без огурцов будет изготовлен "с нуля".
Автопроизводители также откладывают вариации до последнего возможного
момента. Опционные пакеты добавляются в конце, когда спрос понимается луч­
ше. Необычные предметы, такие как специальные аудиосистемы или шикарные
шины, добавляются дилером только после того, как тот или иной конкретный
клиент запросит их специально.
Пока незавершенная работа остается стандартной, процесс остается прос­
тым . Вы можете массово производить десятки унифицированных гамбургеров
с помощью одного производственного процесса и с единственной целью, что­
бы сделать ero более эффективным. Как только процесс настроен, его можно
90 Часть 1. Инновационные стратегии

специализировать. Наша способность совершенствовать процесс не отменяется,


а откладывается во времени.
Эта стратегия также работает в сфере информационных технологий. Необ­
ходимо проектировать системы и процессы, чтобы как можно дольше помер­
живать стандартность незавершенной работы. Откладывайте вариации на конец.
Это уменьшает комбинацию конфигураций и переменных, которые необходимо
протестировать, упрощает проверку полноты и точности и упрощает процесс.
Мы уже видели это в нашем обсуждении процесса приема на работу, в кото­
ром стандартные задачи выполнялись первыми.
Другой п ример касается раздачи ноутбуков. Представьте себе компанию,
в которой все новые сотрудники получают один и тот же ноутбук, одну и ту же
операционную систему, одну и ту же конфигурацию и одни и те же приложе­
ния. Однако, когда пользователь входит в систему в первый раз, на ноутбуке
устанавливаются определенные приложения в зависимости от того, кем является
сотрудник: инженером, продавцом или руководителем. После этого клиенты мо­
гут настроить компьютер по своему усмотрению. Это позволяет сохранить весь
процесс развертывания ноутбука унифицированным до последнего момента.
Теперь представьте, что такие настройки были сделаны в самом начале. Если
бы в компании появилось много новых инженеров, то IТ-отдел мог бы оказаться
без инженерных ноутбуков, но с большим количеством ноутбуков для продав­
цов. Если бы аппаратное обеспечение было одинаковым, они могли бы по край­
ней мере переделать ноутбуки специально для инженеров. Это удвоило бы уси­
лия, затрачиваемые на каждый ноутбук, но решило бы конкретную проблему.
Однако, если бы а ппаратные модели были разными, инженеры должны были
бы долго ждать ноутбуков, поскольку устройства не являются взаимозаменяемы­
ми ресурсами. В качестве альтернативы инженеров можно было бы переобучить
на продавцов, но это было бы глупо, поскольку люди не являются взаимозаменя­
емыми ресурсами.
Если в программном обеспечении вещи различаются между собой, мы можем
относиться к ним как к единому целому, выбирая правильный уровень абстрак­
ции. Контейнеры позволяют обрабатывать все службы как нечто целое, потому
что независимо от того, что находится внутри, системные администраторы могут
просто связываться с ними в унифицированных точках соединения, которые яв­
ляются общими для всех.
Некоторые программные структуры разрешают писать дополнения к про­
грамме или драйверы так, чтобы работать с унифицированными вещами, а раз­
личия учитываются с помощью подключаемых модулей.

3.9. Автоматизация
Согласованность упрощает автоматизацию процесса. Легче разрабатывать
средства автоматизации для крупного рогатого скота, чем для домашних жи­
вотных, потому что у скота меньше сюрпризов и вариаций, меньше вариантов
для тестирования. Автоматизация открывает возможности для администрирова­
ния системы самообслуживания. Веб-сайты и другие инструменты могут предо­
ставить пользователям возможность удовлетворять свои потребности без сторон­
него вмешательства.
Глава 3. Домашние животные и к рупный рогатый скот 91

Вы также можете посмотреть на это по-другому: прежде чем улучшить ситу­


ацию, нужно сделать вещи согласованными. Усовершенствовать что-то несогла­
сованное - все равно что бороться со свиньями: грязно и, вероятно, безнадежно.
Когда все будет согласовано, мы сможем все оптимизировать и свободно экспери­
ментировать. Наши эксперименты могут потерпеть неудачу, но если мы не попро­
буем, у нас не будет возможности что-либо улучшить. По крайней мере, с каждым
провалом мы что-то узнаем. Это не рационализация, которая заставляет нас извле­
кать опыт из неудач: эксперименты, которые являются успешными, ценны, потому
что система была улучшена (оптимизирована). Эксперименты, в свою очередь, -
это опыт, который помогает осуществлять дальнейшие улучшения.
Шаблон хаос => определенность => повторяемость => оптимизация проходит крас­
ной нитью через всю книгу. Он также является основой трех способов улучшения
эксплуатационной деятельности, описанной в разделе 12.3.5, и является основой
уровней оценки в разделе 55.3.2.

3.10. Резюме
Домашние животные - это машины, которые невозможно воспроизвести,
потому что они слишком тонко настраиваются в течение длительного перио­
да времени без записи информации о том, как точно воспроизвести процесс.
Они должны управляться индивидуально. Если домашнее животное выходит из
строя, его необходимо осторожно вернуть в желаемое состояние, точно так же,
как врач старается вылечить больного пациента.
Крупный рогатый скот - это машины, которые могут быть воспроизведены
программно и поэтому являются одноразовыми. Если одна из голов скота вы­
ходит из строя, ее ликвидируют, а затем восстанавливают. Для того чтобы за­
вершить аналогию, напомним, что, когда заболевает одно животное из стада, его
убивают, чтобы стадо могло двигаться дальше.
Скотоподобные системы облегчают управление большим количеством ма­
шин. Информационные технологии легче применять массово, если машины яв­
ляются унифицированными.
Рабочие столы можно сделать скотоподобными, одинаково обрабатывая их
в рамках автоматизированного процесса и используя службы каталогов и другие
методы, чтобы сохранить их одинаковость. Мы также можем сократить количество
поставщиков и моделей, чтобы сделать процессы ремонта более стандартными.
У серверов разные задачи. Обычно каждое программное обеспечение работа­
ет по-своему. Мы можем использовать контейнеры и системы управления кон­
фигурацией, чтобы автоматизировать настройку этих различий и обеспечить их
воспроизведение, снова запустив код. Что еще более важно, серверы, похожие
на домашних животных, хранят невоспроизводимое состояние: информацию,
которая не хранится нигде (кроме резервных копий). Мы можем проектировать
наши службы так, чтобы отделить состояние конкретных машин и увеличить ко­
личество скотоподобных систем. Состояние машин может храниться на отдель­
ном файловом сервере, сервере базы данных или внешней службе.
Мы также можем повысить эффективность, сделав процессы более похожими
на крупный рогатый скот. Процесс должен откладывать любые вариации до по­
следнего возможного момента. Сохраняя вещи стандартными в начале, мы мо­
жем начать массовое производство.
92 Часть I. Инновационные стратегии

Упражнения
1. Объясните аналогию между компьютерам и и домашними животными
и рогатым скотом.
2. Что такое "сервер-снежинка"? Почему это плохая идея?
3. Если сервер-снежинка опасен, то как можно уменьшить риск с помощ1,ю
повторения?
4. Как скотоподобные системы помогают повышать эффективность работы?
5. Как скотоподобные системы помогают масштабировать их обслуживание?
6. Используя информацию, приведенную в главе, объясните, почему банки
предлагают низкие процентные ставки?
7. Ноутбук и настольный персональный компьютер сильно отличаются один
от другого. Каким образом их можно рассматривать как скот из одного
и того же стада?
8. Что такое состояние? Что такое невоспроизводимое состояние?
9. Почему изоляция состояния на специальных машинах - хорошая идея?
10. Чем различаются промышленные и бета-среды? Как сделать их макси­
мально похожими?
11. Как откладывание вариаций до конца процесса способствует массовому
производству?
12. Иногда плохое обслуживание клиентов называют скотским. И все же не­
которые из передовых ком паний обеспечивают чрезвычайно высококаче­
ственное обслуживание всех клиентов эффективным и стандартным спо­
собом. Эги компании также управляют людьми, как рогатым скотом. Как
эти компании могут достигать этого, не оскорбляя своих клиентов?
13. Выберите службу в своей организации, которая хранит большое состояние.
Опишите, как это можно реализовать, используя архитектуру, которая
изолирует состояние.
14. Каковы выгоды от переноса вариаций в конец процесса?
15. Выберите процесс в своей организации, который имеет много вариантов.
Как его можно перестроить, чтобы переместить вариации в конец? Каких
выгод можно достичь благодаря этому?
Гл ава 4
Инфраструктура как код

Эта rлава посвящена стратеrии системною администрирования под назва­


нием "инфраструктура как код" (IaC - infrastructure as code), в которой инфра­
структура представляется и управляется с помощью файлов определений, об­
рабатываемых машинами, а не с помощью ручноrо труда. При таком подходе
мы можем управлять своими инфраструктурами, используя такие методы про­
rраммной инженерии, как контроль исходноrо кода, модульные тесты и непре­
рывная интеrрация и поставка (Cl/CD). IaC - относительно новый термин, но он
объединяет мноrо идей, которые присутствовали в системном администрирова­
нии в течение мноrих десятилетий.
В среде IaC мы не вносим изменения в системы напрямую. В место этою мы
обновляем код и данные, которые используются для создания наших сред. На­
пример, вместо тоrо чтобы настраивать мноrочисленные веб-серверы по отдель­
ности, можно использовать текстовый файл конфиrурации, в котором описано,
какие веб-сайты были размещены на каждой из машин. Мы моrли бы написать
проrрамму, которая читает этот файл и соответствующим образом обновляет хо­
сты. При запуске этой проrраммы хосты будут сконфиrурированы в точном соот­
ветствии с файлом конфиrурации. Существующий неб-сервер может оставаться
без изменений. Добавленное определение приведет к автоматическому созданию
новою неб-сервера и, возможно, созданию новой виртуальной машины, на ко­
торой он будет запущен. Веб-сайт с одною сервера на друrой будет перемещен
путем изменения конфиrурационноrо файла и перезапуска проrраммы. Можно
также удалить веб-сайт с одною сервера и добавить ero на друrой. Те же данные
конфиrурации моrли бы управлять обновлением балансировщиков веб-наrрузки,
системы безопасности, доступа к базам данных и т.д.
Коrда мы администрируем системы таким образом, код, который мы исполь­
зуем для управления нашей инфраструктурой, является не просто частью нашей
инфраструктуры - он сам яв.ляется нашей инфраструктурой. Он описывает сете­
вые соединения между машинами, а также между машинами и приложениями,
работающими на компьютерах. Для создания новой машины мы обновляем ма­
шинно-обрабатываемое описание и позволяем ее автоматическое создание. Если
нам не понравится это изменение, мы можем вернуться к предыдущей версии
машинно-обрабатываемою описания. Мы исправляем нашу инфраструктуру
так, как проrраммист исправляет ошибку: изменяем код и проверяем ero в те­
стовой среде. В случае успеха мы передаем ero в производство.
В предыдущей rлаве речь шла о повышении эффективности за счет м ини­
мизации вариации. Стратеrия IaC позволяет лучше поддерживать унифициро­
ванные системы и управлять остальными вариациями. Мы моrли бы относиться
к нашим неб-серверам как к крупному роrатому скоту, единообразно используя
код для создания каждоrо из них. Однако количество такою крупною роrатою
94 Часть 1 . Инновационные стратегии

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


ими, являются вариациями, которые моrут контролироваться инфраструкrурой
IaC. Мы можем лучше комбинировать эти варианты, если делаем это в коде.
Концепция IaC не является отдельным языком или системой программиро­
вания. Это - стратегия. Мы можем реализовать ее, используя либо самостоя­
тельно разработанную автоматизированную систему, либо (предпочтительно)
готовые системы, такие как CFEngine, Puppet, Chef и другие популярные пакеты.
IaC может использоваться для управления каждым уровнем нашей инфра­
струкrуры. Это самый простой способ, если мы начинаем новую компанию или
новый проект. Однако стратегия "все в одном" неуместна в унаследованной или
устаревшей среде. Вы можете начать с контроля одного конкретного аспекта.

4.1. Пр ограммируемая инфраструктура


В п режние времена инфраструкrура не была программируемой. Настройка
машины требовала посещения центра обработки данных, ручной распаковки ма­
шины, ее установки в стойку, подключения кабелей, настройки дисков, подклю­
чения устройства к локальной сети (LAN - local агеа netwoгk) и т.д. Со временем
наша инфраструкrура стала более программируемой. В середине 1990-х годов
вирrуальные локальные сети (VLAN - virtual local area network) позволяли пе­
ремещать ком пьютер из одной сети в другую с помощью программного обеспе­
чения вместо переключения физических кабелей. В конце 1990-х годов сети хра­
нения данных (SAN - storage area network) позволили разделять и разбивать
большой пул дискового хранилища и делать его досrупным для машин в каче­
стве вирrуальных дисков. После 2005 года стали популярными вирrуальные ма­
шины, позволявшие использовать ресурсы одной большой машины для созда­
ния множества меньших вирrуальных машин.
Вся эта вирrуализация приводит к программируемости. Первоначально вне­
сение изменений включало набор команд и их ввод в пользовательский интер­
фейс. В конце концов каждая из этих технологий добавила интерфейсы при­
кладного программирования (API - application program interfaces), которые по­
зволяют автоматизировать эти процессы, используя такие языки, как Java, Perl,
Python и любые другие, которые моrут использовать протокол API. Теперь мож­
но использовать вызовы API для создания вирrуальной машины, распределения
и присоединения вирrуального диска, а также подключения вирrуальных машин
к определенной вирrуальной сети. Ручной труд больше не требуется, равно как
и посещение центра обработки данных.
Облачные службы сделали еще один шаг вперед, предоставив досrуп к вир­
rуальной инфраструкrуре, контролируемой API, без требований к локальной
инфраструкrуре. Облачные службы, такие как Amazon AWS, Google Compute
Platform и Microsoft Azure, превратились из ниши в 2006 году в общеприняrую
деловую практику в 2016 году.
Инсталляция машины свелась к вызову API. Все мы стали программистами.

4.2. Отслеживание изменений


Системные администраторы должны завидовать разработчикам программ­
ного обеспечения. Они сохраняют весь свой исходный код в системах контроля
Гла на 4. Инфраструкrура ка к код 95

версий (VCS - version control system), таких как Git, Mercurial или SuЬVersion. В
результате они моrут просматривать историю файла и видеть, коrда в последний
раз редактировалась каждая строка файла, кем и почему было сделано это изме­
нение.
В листинге 4.1 приведен пример вывода команды g i t annot a t e . Она вы1ю­
дит на экран все строки файла вместе с информацией о том, кто в последний
раз изменял строку, кто и когда утвердил это изменение, а также номер строки
и текст файла.

11истивr 4.1. Вывод команды git annotate


Change i d : ( Au t ho r : Date : L i ne : ) Code :
eae5 64 f2 ( c ra i gp 2 0 1 5- 0 8 - 0 6 172) i s Re l ayed .- r . Heade r .
Get ( r e l ayHeade r )
6 7 b 6 7 bd 0 (mj ibson 2 0 1 5- 0 4 - 2 0 173) reade r :=
&pas s t h ru ( ReadC l os e r : r . Body }
6 7 b 6 7 bd 0 (mj ibson 2 0 1 5-04-20 174) r . Body = reade r
6 7 b 6 7 bd 0 (mj ibson 2015-04-20 175) w : = & re l a yW r i t e r (
6 7 b 6 7bd0 (mj ibson 2 015-04-20 176) Respon s eW r i t e r :
responseW r i t e r }
Ьа83ае2е ( craigp 2015-09-16 177) rp . T S DBProxy . S e rveHTT P ( w ,
r)
ade 0 2 7 0 9 ( ipe t e r s 2 0 1 6- 02 - 2 3 178) i f w . code / 1 0 0 ! = 2
ade 0 2 7 0 9 ( ipeters 2 0 1 6- 0 2 - 2 3 179) verbo s e ( " g o t s t atus %d",
w . code )
6 7 b 6 7 bd0 (mj ibson 2 0 1 5- 0 4 - 2 0 180) return
6 7 b 6 7bd0 (mj ibson 2 0 1 5- 0 4 - 2 0 181) 1
6 7 b 6 7 bd0 (mj ibson 2015-04-20 182) verbo s e ( " re l ayed to t sdb " )
a 6d3 7 6 9b ( c ra i gp 2 015-11-13 183) col l e c t . Add ( " pu t s . r e l a y ed " ,
a 6 d3 7 6 9 b ( c r a i gp 2015-11-13 184 ) opent s db . T agSe t { } , 1 )
· · · · ---···-····· � � " ··--··-· · · · · -·--· -··· ·· · - -·--�---- --·-· .".... .._ .... . .. . ··-· - · ·········· · · · " -

Каждое изменение сопровождается комментарием. В л истинге 4.2 приве­


ден комментарий пользователя ipet e r s к изменению ade 0 2 7 0 9, в котором он
объясняет, почему добавил строки 1 78 и 179.

11истиш· 4.2. Коммента р ии Git


comm i t ade 0 2 7 0 9
Au tho r : i pe t e r s < i pe t e r s @ examp l e . com >
Da t e : Tue Feb 2 3 1 6 : 1 2 : 3 9 2 0 1 6 - 0 5 0 0

cmd / t sdbr e l a y : a ccept responses w i th 2 хх code

ope n t s db may return 2 0 4 o r 2 0 0 on s ucces s fu l PUTs to / a p i /put .


2 0 4 i n d i c a t e s s u cces s w i t h no response bod y , but when t h e
de t a i l s pa rame t e r i s spe c i f i e d , а 2 0 0 i s r e t urned a l ong w i t h а
s imp l e response docume n t . t s dbr e l a y should r e l a y a l l succe s s fu l
P U T s t o bosun .

I am expl i c i t l y not chang ing r e l ayMetada t a , s ince bosun i t s e l f


appe a r s t o o n l y r e t u rn а 2 0 4 .

Системы VCS разрешают видеть всю хронологию файла. Мы можем точно уз­
нать, на что файл был похож вчера, месяц назад или 2 декабря прошлого года.
Сопоставьте это с тем, как мы прослеживаем хронологию изменений на сер­
вере. Да, файлы имеют метки времени; таким образом, мы знаем, когда файл
96 Часть 1. Инновационные стратеrии

был изменен в последний раз. Однако мы не знаем, что именно в файле было
изменено, кто сделал это изменение и почему. Без углубления в содержание ре­
зервных копий мы не имеем никакой хронологии изменений.
Например, однажды команда Тома работала с группой, состоящей из десяти
веб-серверов, которые все были настроены одинаково, по крайней мере они так
думали. Кто-то заметил, что на одной машине параметр, задающий размер се­
тевого буфера, задан иначе, чем на других. Почему? Было ли это изменение слу­
чайным? Кто-нибудь сделал опечатку на этой машине? Возможно, кто-то экспе­
риментировал с разными размерами буфера для достижения лучшей произво­
дительности, но забыл очистить, когда закончил работу. Было ли это изменение
преднамеренным? Какова ожидаемая выгода? Может быть, он работал над проб­
лемой, которой больше не существует?
Если бы машина вышла из строя и должна была быть восстановлена, кто-ни­
будь мог бы внести это изменение? Если это изменение требовалось для конкрет­
ного приложения, то было бы трудно заставить это приложение работать снова.
Исходный код в системе VCS не имеет такой проблемы. В системе VCS код не
появляется ниоткуда. Код можно прокомментировать. Если комментарии отсут­
ствуют, то мы можем использовать VCS, чтобы увидеть примечание, прикреп­
ленное к определенному изменению, или узнать, кто внес изменения, и погово­
рить с этим человеком напрямую.
Еще один момент, который следует учитывать, - это то, что программное
обеспечение обладает уникальным свойством, которого вручную выполняемая
работа не имеет: оно является многоразовым. Если вы напишете функцию, кото­
рая сортирует список целых чисел, то вам не нужно будет писать другую функ­
цию, которая сортирует 10 целых чисел, еще одну, которая сортирует 11 целых
чисел, и еще одну, которая сортирует 12 целых чисел. Одна и та же функция мо­
жет сортировать список любого размера. Вы даже можете создать функцию сор­
тировки, чтобы она выполняла правильные действия с целыми числами, строка­
ми или почтовыми индексами.
Теперь рассмотрим, как традиционно управляются ком пьютерные системы
и сети. Мы оказываемся в бета-среде, которая организована в одном стиле, и в
производственной среде, которая устроена по-другому. Тем временем наши раз­
работчики создали третью систему, которая создает песочницу для разработки
на собственных машинах.
Лучше иметь одну функцию, которая принимает параметры для указания
конкретных изменений. Например, функция, которая инсталлирует среду, мо­
жет включать параметры, которые указывают, является ли эта среда производ­
ственной, бета-версией или средой песочницы. Фундаментальная логика оди­
накова для всех сред. Изменяются только количество машин, а также их име­
на и местоположение. В рабочей среде могут быть сотни реплик, настроенных
для работы с динамичной производственной базой данных. В бета-среде может
быть меньше реплик, настроенных для взаимодействия с отдельной базой дан­
ных, полной искусственных тестовых данных. В среде разработки может быть
только одна реплика каждого типа службы, взаимодействующая с крошечной
базой данных, и все эти службы работают на одной машине, возможно, на собс­
твенном ноутбуке разработчика.
Параметризованный код минимизирует процедурные различия между
различными средами. Изменение процедуры настройки службы не должно
Глава 4. Инфраструктура как код 97

выполняться три раза. Эrо уменьшает вероятность того, что процедура бета-сре­
ды окажется не синхронизированной с производственной процедурой . Эrо так­
же уменьшает вероятность ошибок, которые проявляются на производстве, но не
мoiyr быть воспроизведены в другом месте.
Представьте, что наша инфраструктура полностью управлялась бы, как код.
Каждое изменение осуществлялось бы путем обновления машинно-обрабатыва­
емых файлов определений, которые при обработке создавали или удаляли ма­
шины, настраивали системы, создавали файлы, запускали процессы и т.д. Мы
получили бы возможность отслеживать изменения, знать историю нашей ин­
фраструктуры и определять, кто и какие изменения внес. Наша инфраструктура
была бы параметризована, чтобы мы могли строить одну и ту же среду с разны­
ми количествами, именами и местоположениями машин. Системное адм ини­
стрирование может пожинать плоды, которыми пользуются разработчики про­
граммного обеспечения в течение десятилетий.
Вот в чем, в двух словах, заключаются основы IaC.

4.3. Выгоды инфраструктуры как кода


Стратегия IaC приносит выигрыш в стоимости, скорости и риске.
Стоимость снижается, потому что ручной труд уменьшается или вообще
устраняется. Автоматизация - это масштабный множитель рабочей силы: она
позволяет одному человеку выполнять работу многих. Объем ручной работы
растет линейно: чем больше задач нужно выполнить, тем больше людей необхо­
димо нанять. Без такой автоматизации огромные компании, такие как Facebook
и Google, в конечном итоге должны будут нанять всех существующих системных
администраторов.
Скорость растет. Задачи мoiyr выполняться не только быстрее, но и парал­
лельно. Их можно выполнить, не дожидаясь, когда человек станет доступен
для работы. Дни ожидания, пока системный администратор выполнит пяти­
минутную задачу, являются общим препятствием для производительности ко­
манды.
Риск снижается многими способами. Риск с точки зрения безопасности сни­
жается, потому что мы можем доказать соответствие. Иначе говоря, мы можем
быть уверены, что различные элементы управления находятся в безопасном со­
стоянии. Мы можем уменьшить риск ошибок, применяя правильные методы
проектирования програм много обеспечения. Например, код можно сначала
протестировать в бета-версии или в тестовой среде. Лучше обнаружить ошибку
в тестовой среде и исправить ее там, чем терпеть последствия ошибки, возник­
шие на производстве.
Стратегия IaC делает вашу среду прозрачной для других. Вы можете докумен­
тировать входящие предложения и причины, по которым вы принимали раз­
личные проектные решения.
Эrо облегчает вовлечение новых членов команды в ваш проект. Аудит вашей
среды становится проще. Аудиторы мoiyr один раз провести проверку вашего
кода, а затем проверить все последующие изменения. Без IaC аудиторы должны
каждый раз просматривать каждый дюйм каждой машины.
В исследовании операций есть принцип, гласящий, что дефекты не должны
передаваться вперед. На автозаводе это означает, что если корпус неисправен, то
98 Часть 1. Инновационные стратеrии

необходимо как можно скорее обнаружить эту проблему. Если вы сразу обнару­
жите ее, то сможете отказаться от шасси или переработать его. В противном слу­
чае вы можете получить автомобиль стоимостью 45 тысяч долларов, который не
может быть продан. Если было установлено неисправное шасси, то вся работа, за­
траченная на остальные производственные процессы, представляет собой пустую
трату ресурсов компании, которые можно было выделип, для испра1шых авто­
мобилей. (Конечно, ремонт неисправного автомобим1 может восстановить часть
капитала, потерянного при его изготовлении, но это требует еще большего труда).
Аналогично в программном обеспечении или в методологии IaC мы хотим
обнаружить ошибку как можно раньше, чтобы она могла быть исправлена рань­
ше (в лучшем случае), или по крайней мере не позволить ей достиrнуть стадии
производства (наихудший случай).
Чтобы определить, что такое плохо, необходимо определить, что такое хо­
рошо. В автомобильном мире есть определение того, что такое хорошее шасси.
Производители знают его ожидаемый вес, высоту, длину и форму. Они могут
выполнять визуальный осмотр вмятин.
Определить, что такое хорошо для стратегии IaC, сложнее. Мы можем выпол­
нить визуальный контроль кода, но единственный способ точно знать, что код
хорош, - выпустить его. Поскольку мы не хотим выполнять код до его тестиро­
вания, мы должны выполнить его в тестовой среде. Там мы можем использовап,
различные тесты.
• Дымовые тесты (smoke tests). Они проверяют основные функциональные
возможности. Название происходит из мира электроники, где дымовой
тест означает включение устройства. Если из устройства идет дым, значит,
с ним что-то не так. Дымовой тест позволяет просто проверить, что файл
конфигурации синтаксически правилен, с помощью запуска программного
обеспечения и проверки, не даст ли оно немедленный сбой.
• Модульное тестирование (unit tests). Вы выполняете части кода - воз­
можно, определенную функцию или модуль - с искусственными входны­
ми данными и убеждаетесь, что резул1,тат соответствует ожидаемому. Каж­
дая часть тестируется по-отдельности. Например, функция, которая фор­
мирует новое имя машины на основе его местоположения и назначения,
может получать комбинации местоположений и других данных для про­
верки ожидаемых результатов.
• Тестирование интеграции (integration tests). Вы запускаете всю систему,
чтобы проверить, как все части работают вместе. Например, вы можете
создать DНСР-сервер и несколько машин, представляющих типичные кон­
фигурации. Затем вы проверяете, все ли они получили свои сетевые конфи­
гурации с сервера DHCP.
• Приемочное тестирование (acceptance testing). Проверяет, соответству­
ет ли система потребностям клиента, часто путем ввода реальных данных
в систему и проверки желаемых результатов.
• Наrрузочное тестирование (load testing) . Проверяет производительность
системы. У вас может быть определенный тест на то, находится ли прои:i­
водительность в пределах ожидаемых параметров. Обнаружив, что новая
версия значител1.но медленнее предыдущих, этим простым способом мож­
но предотвратить снижение производительности.
Глава 4. Инфраструктура как код 99

Мы можем применять для системного администрирования методы Cl/CD,


ранее рассмотренные в разделе 1 .2.2. Любое изменение кода (инфраструктуры)
проверяется в системе VCS. Она запускает автоматизацию, которая выполняет
тесты перед внесением желаемых изменений.
На рис. 4.1 показана платформа предоставления услуг. Здесь стратегия IaC
позволяет полностью отразить цикл жизни поставки программного обеспечения
в нашей инфраструктуре. В верхней части показано традиционное прикладное
программное обеспечение, перемещающееся через систему Cl/CD: оно создает­
ся, упаковывается, проверяется, одобряется и инсталлируется на производстве.
В нижней части показано применение стратегии IaC к тем же самым процессам.

Шаблон п роектирования платформы предоставления услуг

Разрабош Утверждение Создание Упаковка Регистрация Продвижение Иж:талляция Нааройка

Хранипище
нсходных
�одов
: :

Создание Развертывание

Рис. 4.1. Части шаблона проектирования современной платформы предоставления услуг (пере­
печатывается с разрешения д.�мона Эдвардса (Dатоп Edvwards) иJ компании DTO Solиtioпs)
100 Часп. 1. Инно11а11ионные стратегии

Т ест на отказоустойчивость
Другим типом теста, который может выполнить система IaC, является тест
на отказоустойчи1юсп,. Подобно медицинскому устройству, которое авто­
матически отключается, если радиация достигает предельно допустимого
уровня, тест на отказоустойчивость проверяет ситуации, которые не должны
произойти, или ситуации, которые могут произойти только из-за ошибки
в коде.
Том создал систему IaC для управления сложной инфраструктурой DNS при
переполнении стека. Она включала проверку на отказоустойчивость, кото­
рая препятствовала тому, чтобы определенные IР-адреса подвергались воз­
действию извне. Это может произойти из-за опечатки, ошибки или непра­
вильного шаблона. Несмотря на то что ни одно из этих событий не должно
произойти, проверка отказоустойчивости системы работала и отказывалась
выполнять обновления, если они все же происходили во время работы.

4.4. Принципы инфраструктуры как кода


Принципы IaC перечислены ниже.
• Вносите все изменения в файлы определений. Конфигурация определя­
ется в файлах данных, обрабатываемых машиной, и в описаниях выполняе­
мых файлов, таких как манифесты Puppet, рецепты Chef или Dokerfiles. Не
регистрируйтес1. на сервере для внесения изменений, пока не проведете ла­
бораторные исследования в процессе подготовки к со:цанию таких файлов.
• Документируйте системы и процессы в коде. Источником истины
должны быть файлы IaC, а не диаграммы и рукописная документация. Код
выполняется точно и последовательно. Схемы и другая документация, по­
нятная человеку, поле:шы, но должны генерироваться по коду.
• Используйте систему VCS для всех файлов. Код IaC должен храниться
в системе VCS. Это относится к исходному коду, файлам конфигурации
и файлам данных - фактически ко всему, что изменялось вручную. Таким
образом, мы знаем историю изменений, кто их внес и почему. Эта запись
может быть проверена и использована при отладке проблем и для быстро­
го отката.
• Применяйте принцип CI/CD. Запускайте тесты и другие процессы при
каждом изменении. Таким образом, мы идентифицируем ошибки по мере
их появления. Когда одно изменение нарушает другую часть системы, мы
немедленно это обнаруживаем. Легче исправить что-то, пока код свеж в на­
шей голове, а не несколько дней или недель спустя, когда он попадет в про­
изводство.
• Применяйте принцип малых шаrов. Десяток небольших и:�менений за
неделю лучше, чем крупные изменения в конце недели, даже если оба ре­
зультата приводят к одному и тому же финальному коду. Ошибки легче
найти, если они изолированы от небольших изменений. Ошибки легче
Глава 4. Инфраструктура к а к код 101

исправить, если они являются новыми и появились до того, как на них нас­
лоились другие изменения. Небольшие изменения легче отменить или от­
катит�,, чем крупные изменения.
• Поддерживайте постоянную доступность служб. Используйте для об­
новления служб способы, которые не требуют простоя. Таким образом, вы
всегда (или по крайней мере чаще) сможете вносить изменения. В против­
ном случае трудно применять принцип небольших шагов.

4.5. Инструментальные средства


управления конфигурацией
Стратегию IaC позволяют реализовать многие системы. В предыдущей главе
мы обсудили контейнеры Docker и OCI. Они предоставляют способ определить,
как неизменные элементы (образы) создаются и объединяются для создания
служб. Такие системы, как Kubernetes, Mesos и Docker, используют эти элементы
для запуска служб.
Другим методом является использование системы управления конфигура­
цией (СМ - configuration management) для поддержки существующих систем
в более IаС-подобной манере или для создания инфраструктуры "с нуля" . На
моме1п написания книги наиболее популярным и системами управления конфи­
гурацией были Puppet, Chef, CFEngine и AnsiЫe. Каждая из них доступна в фор­
мате с открытым исходным кодом, а также в виде коммерческих версий.
Многие организации создают собственную систему управления конфигура­
цией. Мы рекомендуем не делать этого. Поначалу кажется, что вам легко напи­
сать свою систему управления конфигурацией, но со временем она растет и ее
поддержка становится очень проблематичной. Готовая система управления кон­
фигурацией позволяет использовать функции и исправлять ошибки, которые
поступают от сообщества пользователей: у них есть сеть поддержки (бесплатная
или платная), а ны можете улучшить свои навыки с помощью книг, веб-сайтов
и конференций. Легче нанять кого-то, у кого есть опыт работы в существующей
системе управления конфигурацией, чем научить кого-то понимать одну из раз­
работанных в компании систем.

И спользование поддержки соо бщества


Дистрибутив CentOS 7 изменил способ конфигурирования служб. В ответ
члены сообщества обновили модули Puppet. Когда компания Stack Overflow
решила перейти на систему CentOS 7, машины, которые были сконфигу­
рированы с помощью приложения Puppet, как правило, необходимо было
просто заново инсталлировап,. Приложение Puppet восстановило их со все­
ми службами, сконфигурированными по-новому. Помимо тестирования, по­
требовалось очень немного дополнительной работы. Машины, которые были
сконфигурированы вручную, потребовали гораздо больших усилий. Возмож­
ность использовать поддержку CentOS 7, которую обеспечили другие, стало
преимуществом, которого не могла обеспечить доморощенная система.
102 Часть 1. Инновационные страте!'ии

4.5.1. Декларативный или императивный язык


Системы управления конфигурацией лучше всего и:�вестны по их предмет­
но-ориентированному языку програ м м и рования (DSL - domain-specific
pгogramming language); иначе говоря, по языку, построенному для одной кон­
кретной цели. Система Puppet имеет язык под названием "Puppet", Chef расши­
ряет Ruby до собственного языка и т.д.
Бол1,шинство языков программирования являются декларативными или им­
перативными. На императивном языке код выглядит как список шагов, описыва­
ющих, как что-то сделать. На декларативном языке вы указываете, каким должен
быть конечный результат, и система выясняет, как достичь указанной цели.
Большинство языков, с которыми вы знакомы, являются императивными: Perl,
Python, PowerShell, Bash, Ruby, Go и Fortran. Если вы хотите установит�, список
программных пакетов на машине, вы пишете инструкции, описывающие, как
это делается. Листинг 4.3 - это пример, написанный в псевдокоде.

Листинr 4.3. Псевдокод ддя императивного пакета инсталдяции

f o r pac kage narne in [ " apache " , " open s s h " , " h t tpuni t " , "bo sun "] do
i f package l s l n s t a l l e d ( pa c kage name ) then
p r i n t " Pac kage " package " i s i ns t a l l e d . S k ipping . "
e l se
i f ope r a t i ng s y s t ern == " centos " then
r e s u l t = -yurn i n s t a l l ( pa c kagenarne )
e l s e i f ope r a t i ng s y s tern == " deЬian" then
r e s u l t = apt Гns t a l l ( pa c kagenarne )
else
p r i n t " ERROR : Unknown ope r a t i n g s y s tern
e nd i f

i f e r ro r t he n
p r i n t " ERROR : Pac kage " pac kage " d i d not i ns t a l l !"
e l se
p r i nt " Pa c kage " pac kage " ins t a l l ed s ucces s f u l l y
end f i
end i f
endfor

Как видим, этот код работает с разными операционными системами, разны­


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

Листинг 4.4. Псевдокод для деКll аративноrо пакета 11нсталдяции

requ i red pac kage ( " apache " )


requi red-package ( " openssh " )
requi red-pa c kage ( " w i ne " )
requ i red=pac kage ( " c h r i s trnas " )

Выполняя листинг 4.4, система управления конфигурацией определит, какие


пакеты инсталлированы на машине, и установит все недостающие. Она знает
процедуру инсталляции пакетов на разных операционных системах. Некоторые
системы управления конфигурацией знают, как устанавливать пакеты более чем
Глава 4. Инфрастру кrура ка к код 103

в 25 разных операционных системах и их вариантах. Если требуется поддержка


новой операционной системы, то она добавляется к системе управления конфи­
rурацией. В идеале вам не придется переписывать или изменять свой код - вам
будет достаточно просто выполнить настройку новой операционной системы.
Например, вам, вероятно, придется определить, что пакет имеет одно название
в конкретной операционной системе, а в других системах он на:�ывается иначе.

4.5.2. Идемпотентность
Друтой особенностью систем управления конфиrурацией является то, что они
являются идемпотентными. Эrо означает, что система управления конфиrураци­
ей не будет вносить ненужные изменения. Повторное выполнение одного и того
же кода не должно приводить к изменениям.
В примере, показанном в листинге 4.4, код DSL не будет устанавливать пакет,
если он уже установлен. Эrо идемпотентное поведение. Обновление параметра
конфиrурации или ключа реестра Windows является идемпотеmным: если кон­
фиrурация уже содержит данное значение, то система не изменяется. Добавле­
ние строки в файл не является идемпотентным. Каждый раз, когда выполняется
операция, файл увеличивается.
Эrо звучит как очевидный способ автоматизации, но на самом деле это дей­
ствителыю новшество. Для него нужен дополнительный код, чтобы проверить,
нужно ли что-то сделать, прежде чем делать это.
Предположим, вы написали программу, которая создает файл конфиrурации
для сервера протокола сетевого времени (NTP - Netwoгk Time Protocol). На ос­
нове подгруппы сервера и другой информации она создает файл конфиrурации.
Неидемпотентная система будет просто генерировать этот файл и записывать
его каждый раз при запуске системы. Результатом будет файл с одним и тем же
содержимым, но метка даты файла будет меняться каждый раз. Идемпотентная
система создаст конфиrурацию во временном месте, сравнит ее с файлом конфи­
rурации, найденным n системе, и перепишет файл только в том случае, если они
не совпадают.
Предотвращение ненужного обновления файла является более безопасным.
Меньшее количество операций записи на диск означает меньший износ диска.
Другим преимуществом является то, что мы действительно знаем, когда проис­
ходят и:щенения. Например, если система управления конфиrурацией запуска­
ется каждый час, то мы узнаем, когда произошло существенное изменение, вме­
сто того, чтобы просто знать, что система управления конфиrурацией работает
и беспричинно переписала файл.
Узнав, когда произошло фа ктическое изменение, мы можем инициировать
другие действия. Предположим, нашему серверу NТР нужно будет перечитать
свой конфиrурационный файл в любой момент времени, когда он изменится.
Когда файл конфигурации перезагружается, служба останавливается. Если бы
мы каждый раз отправляли сигнал перезагрузки на сервер NТР, это означало бы,
что служба будет постоянно останавливаться. Идемпотентная система знает, ког­
да произошло фактическое изменение, и может уведомлять NТР-сервер только
в случае необходимости.
Благодаря этой идемпоте1пности мы можем периодически запускать програм­
му управления конфиrурацией. Если необходимо внести изменения, система вно­
сит их. Если и:�менения не требуются, программа управления конфиrурацией не
104 Часть 1. Инновационные стратегии

вносит никаких изменений. Если кто-либо вошел в систему и отменил изменение,


система управления конфиrурацией восстановит его во время следующего запуска.

4.5.3. Предохранители и инструкции


Можно считать, что каждое изменение, которое осуществляет система управ­
ления конфиrурацией, определяется двумя частями. Предохранитель (guard) -

это код, который определяет, "Существует ли уже изменение?" Инструк­


ция (statement)- это код, который пытается внести изменения. Как показано
на рис. 4.2, сначала предохранитель определяет, следует ли выполнить работу.
Если да, то для выполнения этой работы используется соответствующая инструк­
ция. Затем предохранитель снова проверяет, успешно ли внесено изменение.
Обратите внимание, что предохранитель вызывается дважды вместо того, чтобы
использовать третий фрагмент кода, который определяет, было ли изменение
сделано правильно. Разделение каждого изменения на эти две отдельные функ­
ции является внутренней деталью системы управления конфиrурацией. Вам не
нужно писать этот код, если вы не расширяете систему.
Большинство систем управления конфиrурацией имеет режим "пробного
прогона", который перечисляет то, что было бы изменено, но фактически не де­
лает никаких изменений. Это позволяет проверить ожидаемые изменения и ни­
чего больше. Режим пробного прогона легко осуществить с помощью системы
управления конфиrурацией и предохранителей: выполняйте только предохрани­
тели, но не инструкции.

Ош и бка! J

Да

Сделано j Сделано J
Рис. 4.2. Идем потентные �uменения

Происхождение
Концепция предохранителей и инструкций впервые была описана в контек­
сте системного администрирования на конференции USENIX LISA Lisa2004
Треем Харрисом (Trey Harris) в его докладе "Новый подход к разработке сце­
нариев". Он назвал это процедурно-ориентированной разработкой тестовых
сценариев (РТОS -Procedural Test-Oriented Scripting).
Харрис утверждал, что термин 11редохранитель впервые был использован
в монографии Эдсгера В. Дейкстры (Edsger W. Dijkstra) "Guarded Commands,
Nondeterminacy and Formal Derivation of Pгograms", опубликованной в жур­
нале Commu11icatio11s of the АСМ в 1975 году.
Глава 4 . Инфраструктура ка к код 105

4.6. Пр имер инфраструктуры как системы кодов


Наилучший способ понять, как выглядит IaC, - посмотреть на примеры.
Эти примеры включают в себя небольшие фрагменты кода на языке Puppet
для управления различными аспектами машины или машин. Они являются час­
тью более крупной системы управления конфигурацией или системы IaC.

4.6.1. Конфигурирование клиента DNS


В листинге 4.5 приведен пример кода Puppet, который настраивает NТР-сер­
вер на хосте. В системах Windows этот модуль использует имена серверов (стро­
ка 2) для настройки встроенного клиента NTP. На Uniх-подобных системах он
инсталлирует клиентское программное обеспечение NTP, зная, что для опреде­
ленных операционных систем используется друтое имя пакета. Затем он создает
файл конфигурации (ntp . conf) с использованием шаблона, который вставляет
NТР-серверы в соответствующие места.

Листищ· 4.5. Настройка клиента DNS


1 c l a s s { ' ntpc l i en t ' :
2 servers => [ ' ntpl . example . com ' ' n tp2 . examp l e . com ' ] ,
3

4.6.2. Простой веб-сервер


В этом примере мы устанавливаем сервер Apache НТТР и настраиваем его
на обслуживание сайта f i r s t . examp l e . сот и SSL-caйтa s e cond . examp l e . сот.
Файлы HTML для каждого сайта находятся в каталоге / h ome / webda t a /
S I TENAМE / www. Соответствующий код показан в листинге 4.6.

Лио инr 4.6. Код Puppet для настройки сервера Apache


1 class { ' apache ' : )
2
3 apache : : vho s t { ' f i r s t . examp l e . com ' ·

4 port => ' 8 0 ' ,


5 do c root => ' / home /webdat a / f i r s t . examp l e . com/www/ ' ,
6
7
8 apache : : vho s t { ' s econd . examp l e . сот ' :
9 port => ' 4 4 3 ' ,
10 docroot = > ' /home /webda t a / s econd . exampl e . com/www / ' ,
11 ssl => t rue ,
12 s s l c e r t = > ' / e t c / s s l / se cond . exampl e . com . ce r t ' ,
-
13 s s l key => ' / e t c / s s l / s econd . examp l e . com . key ' ,
14

Строка 1 активизирует модуль Apache, который устанавливает программное


обеспечение и создает конфигурацию, заданную по умолчанию. Строки 3-6
определяют первый веб-сайт. Строки 8-14 определяют второй веб-сайт. Стро­
ка 1 1 подключает протокол SSL, а строки 12 и 1 3 определяют, где найти соответ­
ствующие криптографические ключи.
106 Часть 1. Инновационные стратегии

Как и в предыдущем примере, этот модуль правильно учитывает, какая опе­


рационная система используется. Каждая операционная система может исполь­
зовать немного другое название для пакета программ Apache НТТР и записывать
файлы конфигурации в другое место.

4.6.3. Сложное веб-приложение


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

Общее определение Бета -среда Производст во

Ьeta2.exampl@.com prod3.exмiple.com

Рис. 4.3. При.ложение с ба.зой данн ых, сет ью и серверам и приложений

Мы также хотим создать бета-версии и производственные версии этих блогов,


но мы не должны все определять дважды. Кроме того, бета-версия объединяет
две подслужбы на одном компьютере для экономии ресурсов. Производственная
среда разворачивает каждую подслужбу на отдельной машине для максималь­
ной производительности. В листинге 4.7 показано, как для определения двух сред
используется ключевое слово s i t e языка Puppet.

Листинг 4.7; Код на языке Puppet Д.1Ui определения бета-версИи· - ·. ·

1 s i te {
2
Глава 4. Инфраструктура ка к код 107

3 Ыоg { ' be t a ' :


4 dЬ u s e r name => ' be t a u s e r ' ,
5 db-pas sword => ' thepas sword '
6 nodes => {
7 Node [ ' be t a l . examp l e . c om ' ] =>
8 [ B l o g : : Web [ ' beta ' ] , B l og : : Арр [ ' be t a ']
] ,
9 Node [ ' be t a 2 . examp l e . com ' ] => B l og : : Db [ ' be t a ' ] ,
10
11
12
13 Ы оg ' prod ' :
14 db use rname => ' p rodu s e r ' ,
15 db-pas sword => ' anotherpa s sword '
16 nodes => {
17 Node [ ' prodl . examp l e . com ' ] => B l o g : : Арр [ ' prod ' ] ,
18 Node [ ' prod2 . examp l e . com ' ] => Blog : : Web [ ' p rod ' ] ,
19 Node [ ' prod3 . examp l e . com ' ] = > Blog : : Db [ ' p rod ' ] ,
20
21
22
23

В этом случае м ы определили бета-среду для использования двух машин или


узлов. Строки 7 и 8 определяют узел b e t a l и указывают, что он должен запус­
кать веб-сервер (Blog : : Web [ ' be t a ' ] ) и сервер приложений (Blog : : Арр
[ ' b e t a ' ] ) Строка 9 определяет узел b e t a 2 и указывает, что на нем размещен
.

сервер базы данных. Производственная среда определена так, чтобы использо­


вать разные машины для каждоrо из трех компонентов (строки 1 7-19).
Бета-версия и производственная среда различаются только учеп1ыми данны­
ми для доступа к базе данных и местоположением do croot. Все остальное зави­
сит от базовых определений модулей и параметров. (В реальном примере мы не
будем указывать пароль непосредственно в исходном коде. Вместо этого мы бу­
дем использовать функцию, которая извлекает пароли из службы репозитория
защищенных секретов.)
Это описание на высоком уровне. Для тоrо чтобы это работало, мы должны
определить приложение для блога и его подкомпоненты. В системе Puppet это
делается с помощью кода, показанного в листинге 4.8.

Л истин1 4.8. Код Puppet да я определения б доrа


1 app l i cat ion Ы о g (
2 db use rname ,
3 db-pas sword ,
4 docroot = ' / var /www/html '
5 {
6
7 Ы оg : : db { $name :
8 db use rname => $db username ,
9 db-pas sword => $ db-pas sword ,
10 expo r t => S q l [ "Ыоg - $ name " ] ,
11
12
13 Ы оg : : web { $name :
14 docroot = > $doc root ,
15 export => Http [ "Ьlog - $ name " ] ,
16
108 Часть 1. Инновационные стратегии

17
18 Ы оg : : арр ( $ name :
19 consume => S q l [ " Ы og - $ name " ] ,
20 expo r t = > H t t p [ " Ы о g - $ name " ] ,
21
22
23
Этот код указывает, что для создания приложения, называемого блогом (стро­
ка 1 ), необходимо указать три параметра (строки 2-4): имя пользователя и па­
роль, используемые для доступа к базе данных, и параметр d o c r o o t (место,
в котором находятся статические файлы). Если параметр do c r o o t не указан,
по умолчанию будет использоваться каталог /var /www/html.
В строках 7-11 для определения базы данных вызывается функция Ы о g : : db.
В строках 8 и 9 она получает имя пользователя и пароль в качестве параметров.
В строке 10 мы указываем, что сервер базы данных экспортирует или предостав­
ляет доступ к службе Sql [ ] . Полное имя службы будет либо Sql [ ' Ы og-bet a ' ] ,
либо S q l [ ' Ы og-prod] ] в зависимости от того, какое имя используется при вы­
зове блога в строках 3 и 13 в листинге 4.7. Код "Ыog - $ name " означает конкатена­
цию строки "Ыоg-" и имени, указанного в команде блога. Механизм экспорта
службы присваивает ей уникальное имя, на которое могут ссылаться подсистемы.
В строках 1 3-16 листинга 4.8 для определения веб-сервера вызывается функ­
ция Ы о g : : web, в качестве параметра которой используется docroot. В резуль­
тате функция Ы оg : : web экспортирует H t t p [ J аналогично тому, как функция
Ы о g : db экспортировала Sql [ ] .
Последняя часть (строки 1 8-21) похожа на предыдущую, но она к тому же
объявляет, что получает данные, т.е. зависит от ранее экспортированной службы
Sql [ ] . Иначе говоря, сервер приложений требует базы данных.
Со всей этой информацией система Puppet знает, как настроить пять ма­
шин, каждую с соответствующими службами. Поскольку зависимости перечис­
лены явно, ей не нужно запускать сервер приложений до тех пор, пока база
данных не будет запущена. Она знает, что веб-сервер запускается последним.
Если какая-либо из этих подслужб выйдет из строя, система Puppet восстановит
или перезапустит ее.
Это очень простой пример. Его можно значительно усовершенствовать.
• Вместо указания конкретных имен хостов мы могли бы приказать системе
Puppet создать виртуальные машины и запустить на них службы. Вирту­
альные машины могут находиться в нашем собственном кластере VM или
в облачной службе, такой как Amazon AWS.
• Если приложение можно расширить путем добавления реплик веб-серве­
ра, мы могли бы добавить параметр, который указывает, сколько реплик
необходимо создать, и позволить системе Puppet создавать столько вирту­
альных машин, сколько необходимо.
• Аналогичным образом мы могли бы уменьшить масштаб системы, чтобы
она помещалась на одной машине. Разработчик, которому нужен частный
клон приложения для выполнения работы, может использовать этот под­
ход для запуска всей системы на своем ноутбуке.
Глава 4. Инфраструктура к а к код 109

4.7. Применение стратегии iAC


в вашей организации
Начинать применение стратегии IaC бывает страшновато, особенно в уже сущес­
твующей среде . Наилучшая стратегия - начать с малого. Автоматизируйте один
аспект на одной машине, чтобы работать стало удобнее. Затем постепенно пере­
ходите к управлению большим количеством аспектов системы и создавайте среду,
в которой все изменения производятся через систему управления конфигурацией.
Первый шаг - выбрать систему управления конфигурацией, которую вы будете
использовать. Популярные варианть1 - Puppet и Chef. Большинство систем управ­
ления конфигурацией являются открьm,1ми, но имеют коммерческую версию, вклю­
чающую службы помержки. Версия с открытым исходным кодом часто представля­
ет собой группу инструментов, которые вы должны собрать воедино. Коммерческая
версия обычно объединяет их вмесrе, часто с дополнительными компонентами, не
являющимися открытыми исходными кодами, чтобы обеспечить полнофункцио­
нальную среду. Эга среда обычно инкапсулирует хранилище исходного кода (или
доступ к вашему хранилищу), систему CI/CD и другие компоненты.
Следующим шагом будет управление одним файлом на одном компьютере.
Эго обеспечит базовую инфраструктуру. В системе Unix хорошим местом для на­
чала является управление файлом / e t c /motd, тогда ошибки не выведут машину
из строя. Затем переходите к управлению этим файлом на многих компьютерах.
Эго позволит проверить возможность масштабирования системы.
После того как дополнительные машины заработают, начните управлять дру­
гими аспектами машины. Обычно начинают с конфигурации клиента NTP, пото­
му что это почти безопасно. Плохо настроенный клиент NTP обычно не вызывает
немедленного отключения. Следующим шагом с низким уровнем риска является
управление набором общих пакетов, которые полезны для всех машин, таких как
обычные утилиты, которые большинство людей устанавливают в любом случае
и которые не причиняют вреда, если они инсталлированы, но не используются.
Следующим хорошим шагом является контроль общих параметров и парамет­
ров безопасности, но убедитесь, что вы выбираете бесспорные значения.
Популярная стратегия состоит в том, чтобы система установки операционной
системы создала минимальную конфигурацию и использовала систему управ­
ления конфигурацией, чтобы вывести ее из этого состояния в полностью скон­
фигурированное. Эга стратегия устраняет необходимость в любом контрольном
списке ручных задач, которые должны быть выполнены на новых машинах. Она
гарантирует, что все машины начнут работать одинаково и останутся управля­
емыми. Теперь, когда система стала более зрелой, используйте подход Cl/CD.
Существует множество открытых и коммерческих вариантов. Возможно, в вашей
организации уже есть система Cl/CD, которую вы можете использовать. Если нет,
любой из популярных вариантов, вероятно, удовлетворит потребности типичной
команды системных администраторов.
Систему CI/CD можно усовершенствовать, чтобы добавить автоматическое
тестирование. П ростой тест для добавления - это проверка синтаксиса кода
и остановка, если есть какие-либо ошибки. Эгот дымовой экспресс-тест предот­
вращает передачу в производство явно плохого кода. Большинство систем имеют
некий каркас тестирования, который облегчает проведение более глубокого тес­
тирования.
110 Часть 1 . Инновационные стратегии

4.8. Инфраструктура как


код для усиленного сотрудничества
Стратегия IaC может улучшить вашу способность к сотрудничеству. По­
скольку все системные изменения хранятся в системе VCS, вы можете использо­
вать функцию совместной работы VCS, известную как запрос на слияние (MR -
merge request) (иногда называемы й запросом на включение (PR - pull request)).
С помощью запроса на слияние можно не передавать измененный файл в сис­
тему VCS напрямую, а сначала рассмотреть это изменение и уrвердить его. Си­
стема VCS управляет очередью запросов на изменение, подобно тому, как си­
стема управления билетами управляет запросами пользователей.
Представьте, что вам нужно изменить конфиrурацию балансировщика нагруз­
ки. По мере необходимости вы редактируете файлы IaC и посылаете сотруднику
запрос на слияние. Сотрудник анализирует изменения и, возможно, предлагает
некоторые исправления или предложения. После нескольких итераций и реви­
зий изменения утверждаются, и система VCS разрешает вам их отправить.
Этот подход имеет ряд преимуществ. Во-первых, одна голова хорошо, а две -
лучше. Если кто-то еще просмотрит изменение, то вы, скорее всего, найдете
ошибку.
Во-вторых, это хороший способ наставничества и обучения начинающих сис­
темных администраторов. Предположим, что вы новичок в системе. Находящий­
ся рядом более опытный человек обеспечивает обратную связь - отличный спо­
соб учиться.
Наконец, в-третьих, вы можете использовать этот подход, чтобы запросы
на изменение реализовывались самостоятельно. На создание пользовательского
веб-интерфейса, который позволяет пользователям вносить изменения в службу,
может потребоваться много времени. Для сравнения - предоставить сотрудни­
кам документацию, позволив им отправлять запросы на уrверждение измене­
ний, достаточно легко.
Например, в компании Stack Overflow любой инженер может запросить обнов­
ление DNS, отредактировав правильный файл IaC и отправив запрос на слияние
команды SRE для уrверждения. Это позволяет команде SRE применять стандарты
именования и предотвращать неудачные изменения, не требуя от членов команды
самостоятельною внесения каждого изменения. Это - способ безопасного делеги­
рования работь1 другим. Докумеmировать, как редактировать файл, намноrо проще,
чем писать веб-интерфейс. Таким образом, предотвращаются ошибки, группа SRE
и разработчики моrут сотрудничать, передавая предложения вперед и назад, а об­
новления делегируются разработчикам, оставляя последнее слово за группой SRE.
Запросы на слияние обычно используются для обновления конфиrураций ба­
лансировщика нагрузки и системы мониторинга, правил оповещения и выполне­
ния других межгрупповых запросов.

4.9. Недостатки инфраструктуры как кода


У стратегии IaC есть некоторые недостатки.
Прежде всего, кривая обучения может быть круrой. Конечно, это справедливо
почти для всех технологий. Используйте одну систему, а не распыляйте усилия.
Используйте запросы на слияние, чтобы облегчить обучение новых сотрудников.
Глава 4. Инфраструктура ка к код 111

Кроме того, некоторые критики стратегии IaC отмечают, что ее применение


требует от системных администраторов больше навыков программирования, чем
администрирования. Это неизбежная тенденция. С течением времени работа
системного администратора уходила от физических задач в сторону програм­
мирования. В 1980-е годы главным навыком системного администратора была
возможность изготавливать вручную кабели Ethernet. Теперь такие навыки счи­
таются устаревшими и пустой тратой ценного времени системного администра­
тора. Подобным образом мы все чаще и чаще рассматриваем выполнение задач
вручную. В частности, виртуализация и интерфейсы API приводят к тому, что
системные администраторы становятся разработчиками.
Вы должны поощрять культуру ведения дел с помощью систем управления
конфигурацией. Новые проекты должны рассматриваться не как "сделай то-то
и то-то", а как "автоматизируй то и это".

4. 10. Мифы об автоматизации


Есть три мифа об автоматизации, которыми мы хотели бы завершить наш
рассказ.
Автоматизация чем-то опасна. Это обычно формулируется в форме "Что если
я сделаю опечатку и сотру все диски сервера?"
Реальность такова, что и ручные шаги, и автоматизация создаются людьми,
а люди ошибаются. Разница в том, что автоматизация может быть проверена
до того, как будет внедрена в производство. Люди часто становятся ленивыми
или самоуверенными и пропускают предварительные проверки или не проверя­
ют свою работу после ее завершения. Если эти проверки закодированы в автома­
тизации, то они будут выполняться каждый раз.
Автоматизация обеспечивает согласованность. Это может привести к посто­
янно хорошей или постоянно плохой работе. Однако мы можем использовать
методы тестирования и разработки программного обеспечения для измерения
его качества и постепенного улучшения. Любые сбои, небольшие или крупные,
вызванные автоматизацией, должны приводить к новым испытаниям, так что
регрессия, означающая повторение ранее исправленных ошибок, не возникает.
С течением времени программное обеспечение становится все надежнее, по­
скольку в нем исправляется все больше и больше ошибок.
Второй миф закл ючается в том, что ручная работа имеет более высокое ка­
чество. Мы слышали, как люди говорят, что им удобнее делать изменения само­
стоятелыю, потому что "я тщательно проверяю свою рабо1у" . Мы бы предпочли
провести всю эту проверку с помощью автоматизации.
Мы также слышали, как люди утверждают, что они проверяют свою работу
лучше, чем даже их коллеги. Значит ли это, что работа должна остановиться,
когда они уезжают, или что можно работать хуже, когда они находятся в отпус­
ке? Если ваша проверка на самом деле лучше, то, будучи хорошим членом ко­
манды, вы должны автоматизировать процесс, чтобы все делали это хорошо.
Последний миф - если вы автоматизируете слишком много операций, то по­
теряете работу. Это неверно. В вашей организации требуется в сто раз больше
IТ-работы, чем вы и ваша команда можете выполнить. Если вы автоматизируете
задачу, это просто означает, что один из давно отложенных проектов наконец
получит некоторое внимание.
112 Часть 1 . Инновационные стратегии

Мы были на руководящих должносrях и нам приходилось сокращать числен­


ность персонала. Неужели в таких ситуациях мы отпустим человека, который
отлично справляется с задачами автоматизации? Нет, мы отпусrим человека, ко­
торый не умеет автоматизировать работу. Человек, который умеет автоматизи­
ровать задачи, является множителем рабочей силы и поэтому очень ценен. Этот
человек - последний, кого можно отпусrить.
Исrина закл ючается в том, что умение автоматизировать - это умение, кото­
рого хочет каждый менеджер. Это отличает вас от всех других сисrемных адми­
нисrраторов. Фактически мы рассматриваем нашу роль как посrоянную попытку
автоматизировать свою работу. Это освобождает наше время для учасrия в новых
интересных проектах.

4. 11 . Резюме
Инфрасrруктура как код (IaC) - это применение программного обеспечения,
которое лучше всего подходит для сисrемного администрирования. В рамках
этой стратегии поддерживается машинно-обрабатываемое описание инфра­
структуры, а средсrва автоматизации используют это описание для создания
и удаления машин, изменения конфигураций, запуска и осrановки служб и т.д.
Рассматривая эти описания как исходный код, мы можем использовать сисrему
контроля версий, чтобы отслеживать их исrорию, отменять неудачные измене­
ния, выполнять тесты по-отдельносrи и получать все преимущества непрерыв­
ной интеграции и досrавки. Описание плюс программное обеспечение автома­
тизации - это наша инфрасrруктура.
Принципы IaC заключаются в том, чтобы закодировать все изменения в фай­
лах определений, справочных сисrемах и процессах, использовать систему кон­
троля версий для всех файлов, применить Cl/CD к инфрасrруктуре, применить
принцип малых шагов и посrоянно предосrавлять услуги.
Одна стратегия IaC заключается в использовании для создания инфрасrрук­
туры неизменяемых элементов, таких как контейнеры (OCI, Dockeг). Описание
IaC используется для создания повторяющихся элементов. Другая стратегия за­
ключается в использовании сисrемы управления конфигурациями (Puppet, Chef
и др.) для создания и поддержки инфрасrруктуры, которую мы желаем, в по­
вторяемой форме. Использование этих сисrем, а не доморощенных платформ,
позволяет использовать знания и опыт других.
Сисrемы IaC обычно реализуются с помощью декларативных языков. В коде
описывается или объявляется конечный результат, а сисrема сама выясняет, как
его достичь. Этим декларативные языки отличаются от императивных языков,
таких как Python и С, которые описывают, как досrичь цели шаг за шагом. Дек­
ларативные языки более лаконичные и относятся к более высокому уровню аб­
сrракции.
Системы IaC обычно являются идемпотентными. Они проверяют необхо­
димосrь внесения изменений и вносят только необходимые изменения. Запуск
идемпотентной сисrемы второй раз не приводит к изменениям, потому что из­
менения уже были выполнены в первый раз.
IaC позволяет сисrемным админисrраторам сотрудничать более эффективно.
Описание инфрасrруктуры может включать обширные комментарии, которые
окажутся полезными для будущих членов команды. Код может использоваться
Глава 4. Инфраструк�ура ка к код 113

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


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

УпражнеIШя
1. Что такое инфраструктура как код (IaC)?
2. Каковы преимущества автоматизации над выполнением системного адми-
нистрирования вручную?
3. В чем заключаются преимущества IaC?
4. Почему важно знать историю изменений в системе?
5. Что подразумевается под параметризацией программного обеспечения?
Каким образом параметризация обеспечивает повторное использование
программного обеспечения?
6. Каковы основные принципы и методы разработки программного обеспе­
чения, которые были приняты системными администраторами для созда­
ния IaC?
7. Каковы принципы IaC?
8. Что такое неизменные элементы? Как они используются?
9. Что такое идемпотентность? Почему большинство систем управления кон­
фигурацией являются идемпотентными?
10. Чем системы управления конфигурацией отличаются от другого про­
граммного обеспечения, которое системные администраторы используют
для управления нашими системами?
11. Какие системы IaC, если таковые имеются, используются в вашей среде?
12. Опишите стратегию внедрения или расширения использования IaC в ва­
шей текущей среде?
13. Что такое декларативный язык? Чем он отличается от императивного языка?
14. Предположим, вы собираетесь готовить обед. У вас нет ингредиентов, по­
этому вы должны их купить. Затем вы должны смешать и приготовить их.
Наконец вы подаете еду за обеденным столом. Предположим, что мир
контролируется компьютерами. Как бы вы написали программу для при­
готовления обеда с использованием воображаемого императивного языка,
а затем на воображаемом декларативном языке?
15. Изучите основы системы Puppet, Chef или какой-либо другой системы
управления конфигурацией. Используйте ее для настройки простого
веб-сервера.
Часть 11

Управление парком
ра б очих станций
5 Глава

Архитектура ра б очей станции

Одной из главных функций IТ-отдела является управление парком рабочих


станций, используемых организацией. В этой главе речь идет о многих техни­
ческих и нетехнических решениях и о том, как они определяют тип и качество
обслуживания пользователей.
Рабочие станции - это компьютеры, используемые людьми . Будь-то настоль­
ные персональные компыотеры в офисе или ноутбуки, перемещаемые с мес­
та на место, рабочие станции - это компьютеры, которые люди используют
для выполнения работы. Существуют также мобильные устройства, такие как
смартфоны и планшеты, которые все чаще используются для выполнения основ­
ных рабочих задач. Сравните это с серверными компьютерами, которые, как пра­
вило, скрыты в вычислительных центрах и предоставляют услуги или выполняют
вычисления в дистанционном режиме.
Опыт взаимодействия, который люди получают при использовании своих ра­
бочих станций, определяется проектно-конструкторскими решениями, которые
вы принимаете как системный администратор. Важными для клиентов являются
следующие вопросы.
• Доступность. Доступна ли рабочая станция там, где и когда она необ­
ходима? Рабочая станция не нужна, если она не является необходимой
для пользователя.
• Надежность. Является ли рабочая станция надежной или она часто блоки­
руется или зависает? Надежность начинается с хорошего оборудования, но
все больше зависит от своевременного обновления программного и аппа­
ратного обеспечения. Можно ли рабочую станцию быстро починить, если
она выйдет из строя?
• Производительность. Может ли клиент работать с максимальным ком­
фортом? Является ли доступ к функциям и службам гибким и удобным
или, наоборот, трудоемким и утомительным? Сколько времени каждый
день тратится на продуктивную работу по сравнению с дополнительными
усилиями, требуемыми самой системой?
• Способность пользователей действовать. Ограничены ли пользователи
в своих действиях или могут управлять своим окружением? Они полнос­
тью реализуют свой творческий потенциал или ограничены определенным
набором функций? Контролируют ли они, какие приложения могут быть
установлены и находится ли конфигурация под жестким контролем?
• Актуальность. Сколько времени проходит между моментом появления
новой функции и моментом, когда она установлена и готова к использова­
нию на машине?
118 Часть П . Управление парком рабочих станций

Для системных администраторов важно, чтобы машины были п ростыми


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

5.1. Взаимозаменяемость
Рабочие станции должны быть взаимозаменяемым ресурсом: любое подразде­
ление должно быть в состоянии заменить любое другое. Каждый, кто имеет учет­
ную запись, должен иметь доступ к любой рабочей станции. Приложения, кото­
рые нужны клиентам, должны быть моментально доступ ны. Файлы, которые нуж­
ны клиентам, должны храниться на сетевых файловых серверах, а не на локальном
диске, чтобы они были доступны где угодно . Операционная система и приложе­
ния должны обновляться автоматически с минимальным участием или вообще без
участия пользователя . Пользователь рабочей станции должен иметь возможность
настраивать ее, а не выводить из строя или подвергать опасности .
Возможность входа на любую рабочую станцию повышает доступность . В боль­
шой среде настольных ком пьютеров это означает, что человек может сесть перед
любым компьютером, войти в систему и приступить к работе. Это удобно, когда
кто-то работает в другой части здания, вдали от своего ноутбука; когда кто-то хочет
сделать п резентацию с персонального ком п ьютера, встроенного в подиум; для ра­
боты в колл-центре, в котором люди могут п ересаживаться п о разным ячейкам
в зависимости от изменяющегося сп роса; а также если вы забыли свой ноутбук
дома и вам нужна его временная замена.
Ком п ьютеры рано или поздно ломаются . Если человек п ривязан к о пределен­
ной машине, то он не сможет работать до тех пор, п ока ком пьютер не будет
починен . Это создает давление, требующее быстрого ремонта машины . Давле­
ние приводит к ошибкам, что делает ремонт еще более долгим. Восстановление
данных с ком п ьютеров, вышедших из строя, может быть сложным и трудоемким
процессом . Если машины являются стандартными, то заказчику может быть пре­
доставлена новая машина и он может вернуться к работе . В качестве альтернати­
вы клиенту можно выдать замену для исп ользования до тех пор, пока не будет
отремонтирован старый ком п ьютер . В любом случае такая ситуация удобнее как
для кл иента, так и для человека, вы полняющего ремонт.
Если программное обеспечение на ком пьютере п овреждено, то удобно п росто
стереть и перезагрузить машину "с нуля". Чем более стандартной является ма­
шина, тем легче это сделать.
К сожалению, существуют п ределы того, насколько мы можем п риблизиться
к этому идеалу полностью взаимозаменяемой системы.
Для аппаратного обеспечения характерно разнообразие. Внутри организации
одним людям нужны ноутбуки, а другим - настольные ком п ьютеры . Продавцы
Глава 5. А рхитекrура рабочей станции 119

прекращают продавать старые модели, поскольку появляются новые. Некоторые


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

Пр едотвращение доступа к данным дpyroro пользователя


Если пользователь садится и регистрируется на чужом компьютере, получит
ли он доступ к файлам его владельца?
Операционная система Unix была с самого начала разработана для много­
пользовательской работы и поэтому предусматривает права доступа к фай­
лам и другие элементы управления безопасностью как свои неотъемлемые
части. Поль:ювателю без полномочий очень сложно получить доступ к ло­
кальным файлам другого пользователя, если права доступа к файлам заданы
правильно. Однако неаккуратная конфигурация может оставить эти разре­
шения широкодоступными.
Microsoft Windows задумывалась как однопользовательская операционная
система. Раньше, если второй пользователь входил в систему, этот человек
мог получать доступ к любым локальным файлам, оставленным предыду­
щим поль:ювателем. С течением времени ситуация значительно улучшилась,
поскольку были добавлены новые функции безопасности, такие как разре­
шения для файлов NTFS. Однако для обеспечения обратной совместимости
со старым программным обеспечением эти функции часто отключаются или
не исполь:1уются.
. .. J

Другие вариации, изменяющиеся от машины к машине, - инсталлированные


приложения и программное обеспечение. Не всем нужны все без исключения
пакеты программного обеспечения. Было бы расточительно платить за лицензии
на программное обеспечение для машин, где оно не будет использоваться. Кроме
того, программное обеспечение будет занимать много места на жестком диске.
Обновление и поддержание ненужного программного обеспечения было бы пус­
той тратой ресурсов. Кроме того, это снижает безопасность системы: наиболее
безопасное приложение - это приложение, которое не было инсталлировано.
Дополнительные приложения увеличивают возможность атаки, не добавляя ни­
какой ценности. К счастью, мы можем контролировать этот вариант, установив
120 Часть 11. Управление пар ком рабочих станций

стандартную для всех машин базовую инсталляцию и ограничив вариацию до­


полнительных пакетов на компьютерах.
Кроме того, существуют вариации версий программного обеспечения на ка­
ждой машине. Не следует одновременно обновлять пакет программ с версии
1.0 до версии 2.0 на каждой машине вашего парка. Если у нового программного
обеспечения возникнут проблемы, то пострадает вся компания. Лучше модерни­
зировать машины небольшими группами, чтобы проблемы можно было найти
и устранить до того, как они повлияют на всю компанию.
Наконец, для того чтобы все данные хранились дистанционно и к ним обра­
щались по сети, необходим доступ к сети. Однако доступ к сети не всегда возмо­
жен для ноутбуков или других мобильных устройств, а также для рабочих стан­
ций при использовании в отдаленных районах или зонах бедствия.
Теперь, когда мы рассмотрели нашу идеальную архитектуру, ее границы и не­
избежные вариации, мы готовы глубоко погрузиться в отдельные элементы, ко­
торые образуют эту архитектуру. Основными элементами архитектуры рабочей
станции являются само аппаратное обеспечение, операционная система, конфи­
гурация сети, система учетных записей и авторизации, хранение данных, безо­
пасность хоста и протоколирование.
В следующих разделах приведены обзоры каждого из них. Мы обсудим неко­
торые типичные конфигурации в следующих главах.

5.2. Аппаратное обеспечение


Выбор физического оборудования является самым фундаме1ттальным решением,
которое можно сделать. На выбор предлагаются ноутбуки и настольные компьюте­
ры, мобильные устройства и планшеты, а также другие физические устройства.
Мы исходим из того, что читатели этой книги обладают базовыми знания­
ми об аппаратных концепциях, таких как различие между ноутбуком и на­
стольным компьютером, несколькими поставщиками и несколькими линиями
продуктов у каждого поставщика. Существует также выбор между физически­
ми и виртуальными рабочими станциями, а также предоставляется ли рабочая
станция компанией или используется ли стратегия использования собственного
устройства (BYOD - bring your own device). Эти решения будут более подробно
рассмотрены в главе 6.

5.3. Оп ерационная система


Операционная система образует программный уровень, расположенный
между приложениями и оборудованием. Это посредник, который позволяет
многим приложениям использовать один и тот же компьютер.
В рамках нашей архитектуры рабочей станции мы можем предоставить одну
или несколько операционных систем. Существуют основные группы операцион­
ных систем, каждая с небольшими вариациями внутри группы. Основные груп­
пы обычно связаны с определенными поставщиками: Microsoft Windows, Apple
05 Х и Linux. Внутри каждого из них вариантов меньше: у Microsoft и Apple есть
разные поколения операционной системы, выпущенные за эти годы.
Кроме того, у системы Linux есть и разные поставщики, и разные версии от этих
поставщиков. Например, RedHat, UЬuntu, Deblan, CoreOS и другие производители
Глава 5. Архитектура рабочей станци и 121

создают дистрибутивы Linux, упаковывая ядро Linux с различными наборами при­


ложений, утилит и улучшений. Периодически выпускаются новые версии каждого
дистрибутива, между которыми предоставляются небольшие обновления.
Аналогичным образом компании Microsoft и Apple создают разные версии
серверов и рабочих станций для каждой операционной системы. Серверные вер­
сии комплектуются дополнительными функциями или настраиваются с разны­
ми значениями по умолчанию.
Решение о поддержке одной или нескольких групп операционных систем
аналогично обсуждению поддержки разных моделей оборудования. Минимиза­
ция разнообразия приводит к системе, которую легче поддерживать. Принятие
в качестве стандарта только одной операционной системы позволяет сосредото­
чить больше ресурсов для достижения меньшего количества целей. Иначе гово­
ря, поддержка только одной операционной системы может стать очень выгодной
во всех отношениях.
Для организации, которая исторически поддерживала только одну опера­
ционную систему, добавление поддержки второй системы является серьезным
решением. Это решение удваивает инфраструктуру поддержки, состоящей из
подсистем для автоматической загрузки операционной системы, ее исправления
и т.д. Это также означает, что организация должна удвоить объем знаний сотруд­
ников. Одна из стратегий состоит в том, чтобы нанимать людей, которые знают
обе системы. Это решение может оказаться дорогостоящим, поскольку людей
с опытом работы в двух совершенно разных операционных системах трудно най­
ти, и поэтому они могут претендовать на более высокие зарплаты. Другая страте­
гия заключается в увеличении размера команды за счет включения дополнитель­
ных специалистов по каждой операционной системе. Этот подход также связан
с дополнительными затратами и повышенной сложностью.
Независимо от того, существует ли в вашей организации одна стандартная
операционная система или несколько операционных систем, у них есть версии.
Поддерживается ли одна из версий Windows, только последняя или подмноже­
ство? Хорошо определенное подмножество является лучшим решением.
Например, организация всегда имела две официально поддерживаемые вер­
сии операционной системы: текущую и переходную. В какой-то момент текущей
операционной системой была Windows 7. Когда была выпущена Windows 8, все
корпоративные приложения были перепроверены и Windows 8 стала текущей
поддерживаемой операционной системой, а Windows 7 была определена как пе­
реходная. Пользователи могли использовать Windows 7, но ожидали, что к опре­
деленной дате произойдет полный переход на Windows 8. Офис управления про­
ектами разработал план идентификации и перехода всех машин, работающих
под управлением Windows 7. Когда была выпущена версия Windows 8.1, она не
была развернута до тех пор, пока последняя машина с операционной системой
Windows 7 не была удалена. Это решение было следствием политики поддержки
только двух версий операционной системы в любой момент времени. Это так­
же заставило системных администраторов полностью исключить использование
Windows 7, так как они стремились развернуть Windows 8.1. Эта стратегия также
помогла установить расписание демонтажа устаревших операционных систем.
Если старая операционная система демонтировалась до появления новой систе­
м ы Microsoft, то системные администраторы знали, что они двигались в хоро­
шем темпе. Более быстрое устранение старой версии давало им больше времени
122 Часть 11. Управление парком рабочих станций

для подготовки к появлению следующей версии. Замедленное устранение старой


версии вредило их собственным планам и давало дополнительный стимул под­
держивать темп обновлений.

5.4. Сетевая конфигурация


Рабочие станции обычно подключаются к сети с помощью проводных
(Ethernet) или беспроводных (WiFi) технологий. Эти варианты будут более под­
робно рассмотрены в главах 23 и 24, которые посвящены сетевы м технологиям.
С точки зрения архитектуры решение, которое должно быть принято, заклю­
чается в том, какой должна быть конфигурация сети: жесткой (т.е. храниться
на самой машине) или динамичной (т.е. обеспечиваться самой сетью). К парамет­
рам конфигурации относятся IР-адрес устройства, сетевая маска подсети, шлюз
по умолчанию, DNS-cepвepы и т.д.

5.4.1. Динамическая конфигурация


В динамической конфигурации машина запрашивает у сети, какими долж­
ны быть ее параметры конфигурации. Точнее, она запрашивает службу в сети,
которая возвращает эти параметры. В версиях 4 и 6 протокола Интернета (1Pv4
и 1Pv6) этой службой является служба протокола динамической конфигурации
хоста (DHCP - Dynamic Host Configuration Protocol). Вопрос, как машина может
общаться с DНСР-службой по сети, чтобы узнать, как взаимодействовать с сетью,
создает парадокс, который делает проект DHCP таким интересным. Протокол
1Pv6 имеет дополнительную возможность использования системы под названи­
ем "Neighbor Discovery" (ND), которая предоставляет минимальные параметры,
необходимые для настройки хоста 1Pv6 при отсутствии сервера DHCPvб. Тем не
менее это следует считать временной мерой для организаций, которые еще не
развернули сервер DHCPvб.
Динамическая конфигурация позволяет централизованно контролировать сете­
вые конфигурации. Эrу выгоду нельзя недооценивать. Возможность централизо­
ванного управления конфигурациями является ключом к эффективному управле­
нию большим количеством машин. В противном случае приходилось бы посещать
каждую машину даже для самых незначительных изменений. Централизованное
управление конфигурацией машины дополнительно обсуждается в главе 4.
Даже организации без сложных систем управления конфигурацией могут до­
стичь многих из тех же преимуществ для сетевых параметров хоста, используя
динамическую конфигурацию. Например, может возникнуть необходимость из­
менить размер маски конкретной подсети. Когда DНСР-сервер переконфигури­
руется с новым размером сетевой маски для конкретной подсети, каждый ком­
пьютер в этой подсети обновится сам по мере того, как он будет периодически
связываться с DНСР-сервером, чтобы проверить новые параметры. Этот процесс
называется возобновлением аренды (renewing а lease).

5.4.2. Жестко кодированная конфигурация


В жестко кодированной или статической конфигурации параметры конфигу­
рации сохраняются на самой машине. Статическая конфигурация имеет преи­
мущество - работает независимо от того, доступен ли сервер DHCP. Серверы
Глава 5. Архитектура рабочей станци и 123

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


ние зависимости. Например, IР-адрес файлового сервера обычно не меняется.
Зависимость от DНСР-сервера для загрузки является ненужной зависимостью .
. Конечно, DНСР-серверу требуется статическая конфигурация, потому что он не
может сконфигурировать себя сам!

5.4.3. Гибридная конфигурация


Серверы также могут иметь гибридную конфигурацию, в которой сетевые
параметры определяются в локальных файлах, но сервер периодически прове­
ряет параметры сети через DHCP. Этот метод использует запрос DHCP I N FORM
для получения таких параметров, как DNS-cepвepы, NТР-серверы и т.д. Если об­
наружены изменения, система обновляет свои текущие и хранимые конфигура­
ции соответствующим образом. Этот подход сочетает в себе простоту управле­
ния крупномасштабной установкой с целью устранения зависимости загрузки
от DHCP для критически важных серверов.

5.4.4. Применимость
Возможно, вы заметили, что рабочие станции прямо помещены в категорию
сетей с динамической конфигурацией. Хранение статической конфигурации
на хосте делает его менее универсальным. Он может подключаться только к од­
ной подсети, для которой был настроен.
Будучи динамичным, ноутбук может перемещаться между соединениями Wi-Fi
в офисе, дома или в кафе. Пользователям настольных персональных компьютеров
выгодно использовать динамическую конфигурацию сети, поскольку она снижает
требования к навыкам, необходимым для развертывания или перемещения своего
персонального компьютера. Сотрудники, переезжая в новый офис, могут переме­
щать свои настольные персональные компьютеры, пока им не сообщат, к какому
сетевому разъему подключаться. Если реорганизация офисного пространства тре­
бует перемещения многих людей, то динамическая конфигурация сети означает,
что IТ-работа может быть выполнена заранее, вместо того чтобы требовать точно
организованных последовательностей ходов и реконфигураций.
Динамическая конфигурация также менее подвержена ошибкам. Если вы
ожидаете, что пользователь вручную наберет IР-адрес, маску подсети и шлюз
по умолчанию, это будет чрезмерно оптимистичной надеждой. Создание стати­
ческой конфигурации - обязанность системного администратора. Динамическая
настройка предназначена для конечных пользователей. Это позволяет клиентам
быть самодостаточными и не подвергаться опасности.

Значение протокола DHCP

До того как протокол DHCP стал широко использоваться в конце 1990-х го­
дов, пользователи вручную перенастраивали свои ноутбуки каждый раз, ког­
да брали их домой, а затем снова, когда возвращались в офис. Если рабочий
стол перемещался из одного офиса в другой, клиенты открывали уведомле­
ние с указанием номера порта в новом офисе и запрашивали IР-адрес в под­
сети этого порта.
124 Часть 11. Управление пар ком рабочих станций

В начале своей карьеры авторы обработали много таких уведомлений об из­


менениях в сети, тщательно выбирая IР-адрес из файла хоста, подтверждая,
что кто-то не использовал его тайно; и посылая в ответ на запрос IР-адрес,
правильную сетевую маску, шлюз по умолчанию и другие параметры. Важ­
ным умением системного администратора в то время было умение устанав­
ливать эти параметры в разных операционных системах и исправлять ти­
пичные проблемы, возникшие в результате опечаток.
Иногда клиенты могут запутаться и ввести IР-адрес шлюза вместо IР-адре­
са своего хоста. Эго может вызвать отключение для всех пользователей этой
подсети, поскольку маршрутизатор и настольный компьютер вступят в борь­
бу за использование этого IР-адреса. Если вы считаете неудобным спраши­
вать у официанта в кафе имя и пароль для входа в сеть Wi-Fi, то представьте
себе, какой была жизнь до появления протокола DHCP. Если бы DHCP не
был изобретен незадолго до Wi-Fi, то Wi-Fi ждал бы провал.

5.5. Учетные записи и авторизация


Рабочим станциям нужна база данных с именами пользователей, паролями,
группами и соответствующей информацией об учетных записях. С точки зрения ар­
хитектуры решение зависит от того, хранится ли эта информация на самой машине,
передается ли из центральной базы данных по сети или применяется и то, и другое.
Все машины имеют локальную базу данных учетных записей. В системе Unix
есть файлы / e t c /pas swd и / e t c / group. Система Windows хранит локальные
учетные записи в диспетчере учетных записей безопасности (SAM - Secuгity
Accounts Manager).
Когда эта информация становится доступной как сетевая служба, ее обыч­
но называют сетевой папкой. Наиболее распространенным примером являет­
ся Microsoft Active Directory, хотя есть и другие, такие как Apple OpenDiгectory
и RedHat Directory Server. Все они основаны на протоколе LDAP для доступа
к этой информации, подобно доступу к базе данных, и на протоколе Kerberos
для безопасной обработки паролей и аутентификации. Такие службы более под­
робно рассмотрены в главе 40. Старые системы, такие как Hesiod, NIS и NIS +,
в основном ушли в прошлое, и теперь их, скорее всего, можно найти только
в компьютерных музеях и книгах по истории.

Что нового в протоколе LDAP


Упрощенный протокол доступа к каталогам (LDAP - Lightweight Directory
Access Protocol) - это совсем не простой протокол. Его реализации состо­
ят из сотен тысяч строк кода и являются очень сложными. К сожалению,
' по сравнению с протоколом доступа к каталогам системы Х.500 (который
был разработан позднее), он на самом деле относительно тонкий.

Благодаря использованию сетевого каталога одна и та же информация ста­


новится доступной для всех машин. В каталоге хранятся имя пользователя и па­
роль, а также имена компьютеров, которым разрешена авторизация учетной
Глава 5. Архитектура рабочей станции 125

записи. По этой причине кто угодно может использовать одно и то же имя


поль:ювателя и пароль на любом (разрешенном) компьютере. Администрато­
ру не нужно создавать учетную запись на каждой машине отдельно, а также не
копировать или синхронизировать информацию со всех машин после каждого
изменения. Если пользователь покидает организацию, учетная запись в катало­
ге блокируется, и при этом системным администраторам не нужно блокировать
учетную запись на каждом отдельном компьютере.
До появления сетевых каталогов пользователям приходилось менять свои па­
роли на каждой машине, к которой они имели доступ. Это было приемлемо,
когда организация имела один или два больших мейнфрейма, но стало неприем­
лемым, когда организации перешли на отдельные рабочие станции.
Хранение политик доступа в каталоге означает, что они применяются повсе­
местно. В политике может указываться, что любой пользователь с учетной запи­
сью может входить в систему на некоторых компьютерах, но другие компьютеры
предна:шачены исключительно для использования определенными людьми.
Наличие учетной информации, доступной всем машинам, важно даже в том
случае, если у пользователя нет разрешения на вход в систему с конкретного ком­
пьютера. Например, список файлов на файловом сервере содержит имя файла,
нладел1,ца файла и другую информацию. Для создания такого списка файлов
требуется преобразование числовых идентификаторов пользователей в текстовые
имена полыователей. Например, числовой идентификатор 2034 может быть име­
нем пользователя cj lear. Несмотря на то что cj lear может не иметь разрешения
на вход в вашу рабочую станцию, возможность перечислить файлы и увидеть, что
они принадлежат cj lear, является фундаментальной. Это подводит нас к важно­
му аспекту: существует различие между идентификацией, аутентификацией и ав­
торизацией. Идентификация (identity) - это хранение информации о пользова­
теле. В предыдущем примере хранится факт, что идентификационный номер 2034
связан с именем пользователя cj l ear, и наоборот. Эта информация становится
общедоступной для всех подписчиков службы сетевых каталогов, поэтому ее мож­
но использовать для обеспечения единообразного опыта для всех пользователей
на всех компьютерах. Аутентификация (authentication) использует эту информа­
цию и секреты (обычно пароли}, чтобы доказать, что кто-то есть тот, кем себя на­
зывает. Например, пользователь, введя имя пользователя, пароль и операционную
систему, проверяющую эту информацию, выполняет процесс аутентификации.
Процесс аутентификации должен быть тщательно защищен, чтобы предотвратить
мошенничество. Авторизация (authorization) - это то, что пользователю разре­
шено делать. Например, после аутентификации пользователя, независимо от того,
разрешен ли пользователю вход в конкретный компьютер, используется политика
авторизации. Авторизация выполняется после аутентификации.
Хотя службы сетевых каталогов важны, локальные базы учетных записей
по-прежнему используются. Одним из преимуществ такой базы является то,
что информация всегда доступна независимо от того, подключен ли компью­
тер к сети и даже если сервер сетевых каталогов недоступен. Например, для ис­
правления поврежденной или неправильно настроенной машины, которая не
может взаимодействовать с сетью, часто требуется зарегистрировать учетную
запись локального администратора, учетные данные которого хранятся в локаль­
ной базе учетных записей. Возможность хранения различной информации в ло­
кальной учетной записи каждой машины имеет свои преимущества. Например,
126 Часть 11. Управление пар ком рабочих станций

некоторые организации для каждой машины устанавливают уникальный пароль


в локальной учетной записи администратора. Если пользователю требуется до­
ступ администратора, этому человеку может быть указан этот конкретный па­
роль, а не пароль учетной записи в сетевом каталоге, доступ к которому на всех
компьютерах является привилегированным.
Наличие локальной базы данных учетных записей также позволяет пользо­
вателю создать гостевую учетную запись для сотрудника или друга. Это может
быть удобным и в то же время ужасным нарушением политики безопасности
организации.
При поиске информации системы сначала проверяют локальную базу дан­
ных, а затем один или несколько сетевых каталогов. Они кешируют результаты
для повышения производительности и для использования в автономном режи­
ме. Автономный доступ часто называют роумингом или роуминговым профи­
лем. Он особенно полезен для ноутбуков.
Домашние пользователи без крупных IТ-инфраструктур игнорировали пре­
имущества централизованного сетевого каталога примерно до 2013 года. Теперь
система macOS будет хранить пароли в службе iCloud, а система Windows 8 и бо­
лее поздние версии разрешают вход в систему через личную учетную запись
Microsoft (MSA - Microsoft Account). Эти службы удобны для домашних поль­
зователей, но должны быть отключены компаниями, чтобы не хранить учетные
данные безопасности за пределами их собственного контроля.

Важность служб сетевых каталогов


Тот, кто контролирует каталог, контролирует IТ-отдел. На протяжении це­
лого десятилетия, с 1985 по 1995 год, компании Microsoft и Novell публично
отвергали полезность служб каталогов по очень веской причине: они не со­
здали продукт для службы каталогов. Позднее компании Novell и Microsoft
осознали стратегическую ценность служб каталогов. Создание продукта за
продуктом, каждый из которых имеет собственную внутреннюю учетную за- ,
пись, становилось административным кошмаром и увеличивало стоимость
разработки. Когда компания Microsoft перешла от настольных приложений
к ориентации на клиент-серверные продукты, она увидела свет в конце тун­
неля. Вскоре появились службы Novell Directory Services (NDS) и Microsoft
ActiveDirectory, которые вступили в активную конкуренцию между собой -
иногда неэтичную, - пока, наконец, не победила служба ActiveDirectory.

5.6. Хранилище данных


Пользователь рабочей станции должен хранить информацию, или состояние.
Обычно эта информация хранится в виде файлов и каталогов, но также включает
в себя конфигурацию и настройки, которые пользователи делают в своей среде.
Существует три основных способа настройки хранилища.
• Локальный. Все файлы данных хранятся локально. Система настроена та­
ким образом, что файлы пользователя хранятся на локальном диске, ко­
торый также используется для хранения операционной системы и л юбых
Глава 5. Архите ктура рабочей станци и 127

связанных с ней файлов и состояний. Локальные диски часто называют хра­


нилищем с прямым подключением (DAS direct attached storage).
-

• Без состояния. При таком способе настройки нет локально уникальных


данных. Файлы пользователей хранятся на удаленном сетевом сервере.
Любая информация, которая хранится локально, является копией данных,
которые хранятся в другом месте. Локальный диск используется только
для операционной системы, временных файлов и кеша. В идеальном слу­
чае, если бы локальный диск был поврежден, единственной информацией,
которая могла бы быть потеряна, были бы временные файлы одноразового
использования и кешированные копии файлов, оригинальные копии кото­
рых хранятся на удаленном сервере.
• Бездисковый. При этом способе настройки нет локального дискового
хранилища. Операционная система и пользовательские данные хранятся
на удаленном сетевом диске с использованием протоколов, таких как iSCSI
или NFS. Если машина выходит из строя, к заменяющему ее устройству
может быть присоединен один и тот же блок памяти. Эта настройка наи­
более часто используется в виртуальных машинах и блейд-системах, ко­
торые обсуждаются ниже. Часто многие машины, не имеющие дисков,
совместно используют общий образ только для чтения базовой операци­
онной системы, экономя память на сервере. Изменения (дельта) базового
изображения хранятся на отдельном сетевом диске, который является уни­
кальным для машины.
По умолчанию для большинства операционных систем обычно используется
локальное хранилище. Локальное хранилище настраивается просто и всегда до­
ступно. Основной недостаток локального хранилища заключается в том, что оно
является рискованным. Диски рано или поздно выходят из строя. Пользователи
случайно удаляют данные или хотят посмотреть, каким был файл много меся­
цев назад. По этой причине такие данные необходимо резервировать. Это может
быть затруднительным, особенно для машин без доступа к сети или с медленным
доступом к сети. Ноутбуки особенно трудно копировать, потому что они не всег­
да включены . Данные, хранящиеся на сервере, легче резервируются и могут быть
более эффективно защищены с экономической точки зрения с помощью RAID
и других методов, о которых говорится в главе 43.
Локальное хранилище обычно работает быстрее, чем сетевое. Сетевое храни­
лище имеет репутацию медленного, хотя есть и противоположные примеры. На­
пример, если рабочие станции имеют медленные диски и файловый сервер ос­
нащен высокопроизводительной технологией хранения, результатом может быть
сетевое хранилище, работающее быстрее, чем локальный диск. Дополнительные
затраты, необходимые для успешного достижения этой производительности,
амортизируются на многих обслуживаемых рабочих станциях. Если это позво­
лит приобрести менее дорогие рабочие станции, то можно сэкономить деньги.

Обычные диски ИllИ SSD?


Твердотельные диски (SSD -solid state drive) являются наилучшим вариан­
том для ноутбуков и настольных компьютеров. По мере того как цена SSD
128 Часть 11. Управление пар ком рабочих станций

будет падать, они станут стандартными для всех рабочих станций. Традици­
онные диски состоят из механических деталей, которые вращаются. Для того
чтобы прочитать информацию, диск должен вращаться, пока головка чте­
ния/записи не зависнет над правильным расположением данных. Эrо ожида­
ние превышает время, необходимое для многократного чтения информации.
Устройства SSD используют для хранения флеш-память. Флеш-память не
имеет движущихся частей и обеспечивает доступ к любой информации
с минимальной задержкой. Хотя диски SSD могут быть относительно мед­
ленными при выполнении определенных операций, таких как выполнение
непрерывного потока операций записи, при использовании на рабочей стан­
ции диски SSD, как правило, дают только чистый выигрыш.
На момент написания этой книги диски SSD были дороже традиционных
жестких дисков. Однако их цена снижается. Повышение производитель­
ности вполне оправдывает дополнительные затраты, особенно если учесть
стоимость снижения производительности работы, вызванную фрустрацией,
которую порождает медленная машина. Для ноутбуков SSD это выигрыш,
потому что они более устойчивы к повреждениям при падении; кроме того,
жесткие диски ноутбуков часто значительно медленнее, чем настольные
жесткие диски, что подчеркивает преимущество SSD в производительности.
Ранние твердотельные накопители эмулировали старомодные жесткие ди­
ски, предоставляя интерфейс SATA и делая их совместимыми с подключа­
емыми модулями. Эrо помогло им получить признание, но добавило сто­
имость дополнительных разъемов и электроники, которые обеспечивали
эмуляцию. Стоимость была снижена путем подключения SSD к слотам PCie
и переноса эмуляции в программное обеспечение. Некоторые производите­
ли интегрировали компоненты SSD в материнскую плату, улучшая произво­
дительность и снижая затраты.
К тому моменту, когда вы прочтете это, цена SSD вполне может упасть ниже
цены обычных дисков, что делает решение легким.

Для того чтобы создать общие, взаимозаменяемые рабочие станции, необхо­


димо лишить их состояния. Эrо можно сделать несколькими способами.
• Уда11енное храни11ище фай11ов. Клиент получает доступ к хранилищу
с удаленного сервера в качестве сетевого диска или другого механизма, ко­
торый заставляет файлы отображаться, как если бы они были локальными,
но фактически обращается к ним с другого сервера. К таким хранилищам
относятся NFS, популярная в системах Unix/Linux, и SMB, популярная
в Microsoft Windows.
• Сетевая синхронизация или об11ачное храни11ище. Файлы пользователя
хранятся локально, но при первой же возможности копируются в сетевую
службу. Примерами таких хранилищ являются Dropbox, Microsoft OneDrive
и Apple iCloud Drive. Файлы хранятся и обрабатываются локально, но любые
изменения синхронизируются с копией, хранящейся в сетевой службе. Фай­
лы также доступны через интерфейс API, который обеспечивает доступ с мо­
бильного устройства и из программ, таких как веб-приложения, которые
Глава 5. Архитекrура рабочей станци и 129

мoryr сохранять файлы непосредственно на сетевом диске. Как правило,


к ним прилагается пользовательский веб-интерфейс.
Конфи�урации баз данных хорошо работают, когда у пользователя есть боль­
шой объем данных, превышающий объем, который может поместиться на ло­
кальном компьютере. Например, пользователь может иметь терабайты данных
на сервере, но только небольшой жесткий диск на ноутбуке. Ноутбук может ке­
шировать крошечную часть полного набора данных для повышения производи­
тельности, но этот кеш может быть достаточно мал, чтобы поместиться в опера­
тивной памяти или использовать свободное место на диске.
Для хранения данных с сетевой синхронизацией необходим достаточно боль­
шой объем локального хранилища, чтобы в нем помещались файлы пользовате­
ля. Как правило, это означает, что либо емкость локального хранилища должна
быть большой, либо объем хранимых данных должен быть относительно малым.
Если у пользователя есть большое количество быстро изменяющихся файлов,
синхронизация со многими устройствами может оказаться громоздкой. Про­
граммное обеспечение для хранения данных с сетевой синхронизацией обычно
имеет возможность выключать синхронизацию определенных каталогов, что по­
зволяет хранить большие объемы данных в сетевой службе, имея управляемое
подмножество, которое синхронизируется с рабочими станциями. Например,
может существовать большой архив видеозаписей, который не синхронизируется
с локальной машиной. Однако это создает нагрузку для пользователей.
Другое отличие между этими параметрами заключается в том, как они обра­
батывают ситуации, когда сетевая служба становится недоступной из-за отсут­
ствия сетевого подключения или выхода из строя самой сетевой службы. Систе­
ма SMB отключит точку подключения к сети. П рограммное обеспечение, которое
обращалось к данным, сообщит об этом как об ошибке, так же, как программное
обеспечение реагирует, когда USВ-накопитель внезапно удаляется. Клиент N FS
будет ждать до тех пор, пока с сервером cмoryr связаться снова. Вся машина бу­
дет ожидать, пока сервер вернется в строй.
Сетевое синхронизированное хранилище продолжает работать, когда теряет­
ся доступ к сети. Все файлы хранятся и обрабатываются локально. Синхронизация
происходит постфактум. Если к сетевой службе нельзя получить доступ, то синхро­
низация просто приостанавливается. Эrо называется автономным режимом. Он осо­
бенно полезен для пользователей, которые отключены от сети в течение длительного
времени, например во время поездок. После окончательного подключения система
выполняет "синхронизацию догоняющего", обновляя сетевое обслуживание.
Как в удаленном, так и в сетевом синхронизированном хранилище к одним
и тем же файлам можно обращаться со многих компьютеров. Эrо очень удобно
для пользователей, поскольку они всюду видят одни и те же файлы. Если новый
файл создается с одной машины, он вскоре будет виден всем остальным. Одновре­
менный доступ к одному и тому же файлу с нескольких компьютеров требует осо­
бой координации. В противном случае данные могут быть повреждены. В некото­
рых системах по умолчанию используется нескоординированный одновременный
доступ. Обновления файла приходят и применяются по порядку. Если две маши­
ны пытаются добавить запись в конец одного и того же файла, два новых фраг­
мента данных могут быть добавлены в любом порядке просто из-за случайности
того, какой запрос присоединения прибыл первым. Если две машины записывают
данные в середину файла, результат будет непредсказуемым.
130 Часть 11. Управление 11арком рабочих станций

Представьте себе, например, ситуацию, когда на одном компьютере запущена


программа, которая будет читать файл, сортировать содержимое и записывать но­
вую, отсортированную информацию обратно в файл. Другая программа добавляет
данные в конец файла. В зависимости от того, в каком порядке файловый сервер
получает различные команды, новые добавленные данные могут заканчивап.ся
в конце файла, отсортированного в другом порядке, появляп.ся в начале или во­
обще исчезать. Результаты определяются случайно. Если такое нескоординирован­
ное обновление является единственным вариантом, то лучше всего принять меры
к тому, чтобы одновременные обновления одного и того же файла никогда не про­
исходили. Делать это так же просто, как все обновления с одной машины.
Для улучшения одновременного доступа требуется координация. Как пра­
вило, одна машина имеет определенный протокол, который обеспечивает экс­
клю:швный доступ к файлу, чтобы она могла выполнять обновления, незаметные
для других машин. Это называется блокировкой файла. Файл, заблокированный
одной машиной, недоступен ни для одной другой машины. Первая машина об­
новляет файл, а затем разблокирует его. Другие машины теперь видят обновле­
ния и могут по очереди управлять файлом.
П ротокол SMB и другие протоколы автоматически блокируют файл при до­
ступе к нему. Хранилище NFS требует, чтобы программное обеспечение специ­
ально блокировало файл.
Хранилище с сетевой синхронизацией обычно имеет интерфейс прикладного
программирования для блокировки файлов. Однако автономный режим сомает
особые обстоятельства, поскольку по определению интерфейс прикладного про­
граммирования не может использоваться в автономном режиме. Чем дольше ма­
шина находится в автономном режиме, тем больше вероятность того, что другой
компьютер изменит файл. Когда автономный компьютер повторно подключает­
ся и выполняется синхронизация файла, он может обнаружить синхронизацию
файлов, которые были изменены под его собственным упранлением. Некоторые
продукты обеспечивают сложные механизмы согласования. Тем не менее самый
простой метод - это просто обнаружить коллизию и переместить обновленный
файл в другое место, 1юзможно, дав ему имя, которое содержит дату и время воз­
никновения коллизии. Поскольку мы имеем дело с реал1.ными пользователями,
они будут видеть несколько имен файлов и сверять их вручную.
Для того чтобы ресурсы рабочих станций стали взаимо:�аменяемыми, исполь­
зуйте конфигурации, не содержащие данных. Удаленное хранилище файлов
лучше всего подходит для настольных компьютеров с постоянными сетевыми
подключениями. Оно также хорошо подходит для ситуаций, в которых многие
машины нуждаются в доступе к одним и тем же данным, если объем данных
слишком велик для локального хранения или если синхронизация громоздкая.
Сетевое синхронизированное хранилище лучше всего подходит для ноутбуков
или ситуаций, в которых необходим автономный доступ.

5.7. Обновления операционной системы


Необходимо предусмотреть способ обновить операционную систему и приклад­
ное программное обеспечение на машине. Программное обеспечение никогда не
бывает завершенным раз и навсегда: его всегда можно улучшит�•. Пока программ­
ное обеспечение активно поддерживается поставщиком, всегда будут появляться
Глава 5. Архитектура рабочей стан ции 131

обновления, часrо называемые заплатками, которые добавляют новые функции,


исправляют ошибки и закрывают дыры в безопасносrи. Ожидание того, что про­
граммное обеспечение никогда не потребует обновлений, необосновано. У вас долж­
на быть сrратегия развертывания обновлений программного обеспечения. Поддер­
жание машин в аюуальном сосrоянии - часrь хорошей гигиены сисrемы.
Помимо исправления сущесrвующего программного обеспечения, механиз­
мы обновления позволяют развертывать новое программное обеспечение. На­
пример, один и тот же механизм может быть использован для развертывания
нового корпоративного приложения или инсrрумента на всех машинах.
Мы можем усrанавливать обновления вручную или автоматически. Вручную
означает, что человек посещает каждую машину и дает команды для усrановки
обновлений, возможно, даже перезагружает машины, если это необходимо. По­
сещение компьютеров может выполняться как физически, так и через механиз­
мы удаленного доступа, такие как Remote Desktop Protocol (RDP) или Secure Shell
(SSH). Автоматический способ означает использование программной системы
для выполнения обновлений без вмешательсrва сисrемного админисrратора. Ав­
томатическое обновление может происходить по расписанию, например ежене­
дельно, или по требованию, например сисrемным админисrратором, утвержда­
ющим их для групп машин.
Автоматические обновления могут загружать обновления в фоновом режиме
и предоставлять пользователю возможность планировать усrановку и переза­
грузку, возможно, с ограничением периода времени, в течение которого пользо­
ватели могут отложить обновления.
Обновления должны быть автоматизированы по ряду причин. Во-первых, это
масштаб: со временем вы приобретете больше машин и, следовательно, любой
ручной процесс сrанет причиной крупных затрат вашего времени. Во-вторых, ав­
томатизация обеспечивает полноту. Если обновления важны, то они важны даже
тогда, когда вы в отпуске. В-третьих, автоматизация этого процесса гарантирует,
что обновления дейсrвительно будут развернуты. Представьте себе, что вы посе­
щаете каждого сотрудника в компании, чтобы вручную обновить его машины.
Вы могли бы пройти по коридору, чтобы посетить каждого человека. Тем не ме­
нее некоторые люди будут отсутсrвовать или заняты. Вы могли бы отслеживать,
кого вы пропустили, и назначать встречи для повторного посещения. Если вам
повезет, то вы, в конце концов, посетите каждую машину. Однако более вероят­
но, что люди, которых вы посещаете, по какой-то причине не смогут перезагру­
зиться в это время. Вы будете раздражать их, пытаясь перенести всrречу и найти
время, когда вы оба будете доступны. Скорее всего, они начнут избегать вас.
Вероятно, вы вообще не установите эти обновления. Обновления обычно бы­
вают важными, но не срочными. Всегда есть какой-то другой, более срочный
проект, который нельзя отложить. Без усrановки этих исправлений сисrемы сrа­
новятся менее безопасными и менее надежными. Порочный цикл начинается
с задержки обновлений, что увеличивает количество проблем, связанных с безо­
пасносrью и сбоями, с которыми вам приходится иметь дело, что дает вам мень­
ше времени для ручной усrановки исправлений, что, в свою очередь, приводит
к более часrым сбоям.
Наконец, обновления должны быть автоматизированы, потому что это скуч­
ная работа, а вы заслуживаете лучшего. Архитектура вашей рабочей сrанции
должна учитывать следующие соображения.
132 Ч аст ь 1 1 . Управление парком рабочих стан11ий

• Необходимо централизованно контролировать, когда и какие заплатки


распросrраняются.
• Следует проверять обновления до их развертывания.
• Необходимо распросrранять обновления сначала для небольшой группы
пользователей, а затем - для более крупных групп. Таким образом, проб­
лемы будут обнаружены на более ранней сrадии.
• Пользователи должны иметь возможность отложить обновление, но, воз­
можно, только на день или два.
• На информационной панели должно отображаться, какие машины не
были обновлены. Такие машины следует отслеживать, чтобы определить
причину задержки.
• У системного админисrратора должна быть возможность останавливать все
обновления, если обнаружена проблема.
• Системный администратор должен иметь возможность быстро разверты­
вать определенное обновление в чрезвычайной ситуации, что исключает
одобрение пол1,зователя.
Эта тема будет более подробно рассмотрена в главе 7.

5.8. Безопасность
Архитектура вашей рабочей станции имеет много последствий, связанных
с безопасносrью. Мы уже обсуждали политику учетных записей и авторизации,
а также возможность распросrранять обновления системы бе:юпасносrи. Также
необходимо защитить машины от кражи данных, вредоносного программного
обеспечения и изменений в конфюурации сетевого брандмауэра.

5.8.1. Кража
Если ноутбук потерян или украден, первым приоритетом является обеспече­
ние того, чтобы тот, кто обладает устройством, не имел доступа к содержимому.
Мы также хотели бы восстановить устройсrво.
Программное обеспечение для отслеживания ноутбуков периодически объяв­
ляет IР-адрес усrройства службе, которая помогает вам отслеживать ее местопо­
ложение. В случае отсутствия устройства служба может помочь вам найти маши­
ну. Такое программное обеспечение часто имеет функцию удаленной очистки,
которая позволяет стереть содержимое потерянной машины. Некоторые про­
граммы отслеживания позволяют использовать камеры и микрофоны и отправ­
лять периодические обновления, которые помогают отслеживать устройство.
Другой способ защитить доступ к информации на жестком диске - исполь­
зовать полное шифрование диска (FDE - full disk encryption). Механизм FDE
шифрует жесткий диск таким образом, что без кодовой фразы расшифровки
данные на нем в основном становятся непригодными. В большинстве компаний
FDE является стандартной практикой для ноутбуков и мобильных устройств.
Некоторые компании делают это и для настольных компьютеров. Недостатком
является то, что доступ к диску будет предоставляться медленнее, и пользова­
телю придется вводить парольную фразу при каждой загрузке системы. Также
Глава 5. Архитектура рабочей станции 133

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

5.8.2. Вредоносное ПО
Вредоносная программа - это программное обеспечение, со:�данное для тоrо,
чтобы внедриться в машину и подорвать безопасность системы. Часто эта про­
грамма проявляется в виде использования ресурсов или кражи информации.
Вредоносные программы называются по-разному: вирусы, трояны, закладки, шпи­
онские программы и т.д. Антивирусы - это программное обеспечение, которое
обнаруживает эти программы, отключает и сообщает об их существовании. Анти­
вирусное программное обеспечение разделяется на дне основные категории.
• Антивирусное программное обеспечение/черный список. Обнаружи­
вает вредоносные программы, наблюдая за конкретными запрещенными
программами или обнаруживая необычное поведение. Использует черный
список запрещенного программного обеспечения и деятельности, но ра:�­
решает запуск всего другого программного обеспечения.
• Программное обеспечение управления приложением/белый список.
Использует белый список разрешенного программного обеспечения и за­
прещает запуск всех других программ. Этот метод является относитель­
но новым и общепринятым в 2012 году. Предпосылкой является то, что
изначально машины работают в режиме обучения, в котором они соби­
рают информацию о том, какое программное обеспечение используется
в органи:�ации. После этого программное обеспечение работает в режиме
обнаружения, сообщая о появлении любых новых программ. Наконец, су­
щестнует режим предотвращения, который не только обнаруживает новое
программное обеспечение, но и останавливает его работу. Для утвержде­
ния нового программного обеспечения предусмотрена централизованная
панель управления.
Любое программное обеспечение для обеспечения безопасности должно об­
ладать следующими свойствами.
134 Часть 11. Управление парком рабочих станций

• Централизованное управление. Программное обеспечение защиты


должно настраиваться и управляться из центрального пункта. Пользова­
тель может внести некоторые изменения, но не отключить программное
обеспечение.
• Централизованная отчетность. Должна быть предусмотрена централь­
ная панель мониторинга, на которой отображаются состояния всех машин.
Она может показывать, какие вирусы были обнаружены, когда машина по­
лучила последнее обновление аюивирусной политики и т.д. Знание того,
когда машина в последний раз регистрировалась, является ключом к пони­
манию того, было ли программное обеспечение отключено.
• Молчаливое обновление. Программное обеспечение должно обновляться
бесшумно. Не нужно открывать окно, чтобы спросить, нужно ли загрузить
и установить новый черный список аюивируса. Это решение централизо­
ванно принимается системными администраторами, а не пользователем.
• Скрытность. Пользователь должен иметь возможность определить, что
программное обеспечение было активизировано, но анимационный вра­
щающийся шарик состояния или всплывающие окна не нужны, чтобы
объявить, что были сделаны обновления. Такие трюки замедляют работу
машины и раздражают пользователей.
• Незначительное влияние на производительность. Программное обес­
печение для защиты от вредоносных программ может существенно повли­
ять на производительность машины. Рассмотрение каждого блока, считан­
ного с диска, или отслеживание каждого полученного из сети пакета мо­
жет использовать много времени центрального процессора, оперативной
памяти и других ресурсов. При выборе программного обеспечения для за­
щиты от вредоносных программ оценивайте различные продукты, чтобы
оценить использование ресурса.
Сетевой брандмауэр - это политика, реализуемая программным обеспе­
чением, которая определяет сетевое поведение хоста. Например, политика мо­
жет состоять в том, что программное обеспечение, запущенное на аппаратном
обеспечении, может отправлять исходящий сетевой трафик, но входящий сете­
вой трафик ограничивать только ответами на ранее инициированный исходя­
щий рафик плюс некоторый другой назначенный входящий трафик, такой как
доступ RDP из определенных аутентифицированных источников.
Конфигурация межсетевого экрана особенно важна для машин, покидающих
корпоративную сеть. Есть предположение, что находиться в корпоративной сети
безопасно, а за ее пределами - опасно, поэтому конфигурация брандмауэра
может быть менее строгой. Это называется защитой по периметру. В настоящее
время защита по периметру стала менее эффективной, поскольку корпоратив­
ные сети стали более прозрачными.

Продажа ангивирусов
В то время как программы для защиты от вредоносных программ должны
быть тихими и почти невидимыми, многие из них являются яркими и шум­
ными. Почему это происходит?
Глава 5 . Архитекrура рабочей станци и 135

Антивирусное программное обеспечение, продаваемое потребителю, должно


бып, достаточно заметным, чтобы пол1,зователи чувствовали, что получают
деньги. Предста111,те себе, что произойдет, если продукт будет работать неза­
метно, безупречно защищая пользователя, проявляяс1, только один раз в год,
чтобы попросить пользователя обновиться по весьма низкой цене. Компания
разорится. Никто не будет продлевать срок действия, учитывая, что продукт,
по всей видимости, ничего не делал в течение последних 1 2 месяцев.
Коммерческие компании, :Jанимающиеся противодействием вредоносным
программам, хотят, чтобы их клиентам постоянно напоминали, что они на­
ходятся под защитой. Каждую неделю их программное обеспечение появ­
ляется, чтобы сказат1,, что было загружено новое обновление, и попросить
их нажать кнопку " Защити меня", чтобы активизировать его. Продукты
брандмауэра постоянно просят признать, что сетевая атака была защищена,
даже если это был просто ошибочный пакет p i ng. Да, значок анимирован­
ного значка на рабочем столе потребляет ресурсы центрального процессо­
ра и ра:Jряжает батареи портативных компьютеров, но этот вращающийся
трехмерный шарик успокаивает поль:ювателя и подтверждает его решение
о покупке.
Не потребовалось бы меньше программирования, чтобы просто выполнить
обновление, удалить опасный пакет и не отображать всплывающие окна?
Безусловно. Но это снизило бы узнаваемость бренда. Все это работает, пото­
му что есть информационный дефицит. В блоге Брюса Шнайера "А Security
Market for Lemons" (Schneier 2007) объясняется, что типичные потребители
не могут судить о качестве сложного продукта, такого как программное обе­
спечение для обеспечения безопасности, поэтому они уязвимы для этих ма­
хинаций.
Однако вы являетес1, системным администратором, обладающим техниче­
скими знаниями и опытом. Ваша задача - оценить программное обеспече­
ние и определить, что лучше всего подходит для вашей организации. Вы зна­
ете, что антивирусное программное обеспечение должно быстро обновлять­
ся и быть максимально не:Jаметным для поль:ювателей. Ваше решение о том,
следует ли обновлять программное обеспечение, будет основано на данных,
которые отображаются на информационной панели, а не из-за восхищения
вращающимися апимациями .

5.9 . Ведение журнала


Архитектура рабочей станции должна сделать рабочие станции наблюдаемы­
ми. Это делается путем регистрации событий и обеспечения доступности этой
информации.
Мы не можем видеп, все происходящее внутри машины, а если бы даже мог­
ли, то ежедневное круглосуточное наблюдение за каждой машиной не допус­
тило бы масштабирования. Вместо этого машины сами фиксируют различную
информацию. Они регистрируют запущенные программы, проблемы и ошибки,
нарушения политики бе:юпасности и т.д. Эти события должны быть занесены
136 Часть 11. Управление парком рабочих станций

в журнал. В системе Microsoft Windows он называется журналом событий, а в


системе Unix/Linux -системным журналом или s y s l og.
Журналы записываются на диск локально и моrут быть досrупны для просмот­
ра с помощью специальных программ. Другая стратегия - переслать копию всех
записей журнала на центральный компьютер для централизованного хранения,
управления и просмотра. Таким образом, мы получаем глобальную видимость
с одной точки.
Централизованное хранение журналов позволяет проводить более сложный
анализ. Можно наблюдать переход сотрудника с одной машины на другую или
определить самую раннюю дату возникновения конкретной проблемы и соотнес­
ти ее с другим событием, например с обновлением программного обеспечения.
Существует множество средств анализа журналов, таких как Logstash и Splunk,
которые хранят и интерпретируют регистрируемую информацию.
В бол ьших средах используется звездообразная модель ("hub-and-spoke
model"). Каждая группа машин отправляет копию своих журналов в концентра­
тор. В каждом подразделении может быть один концентратор. Затем все кон­
центраторы объединяют журналы и отправляют их в центральный репозиторий.

5.10. Резюме
Рабочие станции - это компьютеры, которыми пользуются люди, будь то на­
стольные компьютеры, ноутбуки или мобильные устройства. Архитектурные ре­
шения, которые вы принимаете, влияют на локальность (где машина может ис­
пользоваться), надежность (как часто она доступна), производительность (моrут
ли пользователи эффективно выполнять свои работы), способность пользователей
к действиям (моrут ли пользователи управлять своей средой и изобретать новые
функции) и текучесть (как часто применяются новые функции и обновления).
В идеале рабочая станция должна быть взаимозаменяемым ресурсом, т.е. любая
единица может заменить другую. Пользователи должны иметь возможность до­
ступа к своим данным с любой рабочей станции. Если рабочая станция ломается,
человек должен иметь возможность перейти на любую другую рабочую станцию.
Однако существуют пределы этой гибкости. Если один пользователь оставляет кон­
фиденциальные файлы, следующий пользователь может получить к ним досrуп.
Лучше всего проектировать сеть с учетом взаимозаменяемости, но ограничивать до­
ступ пользователей, как того требует реальность ограничений безопасности.
Элементь1 архитектуры включают в себя физическую модель оборудования (ноут­
бук, настольный компьютер, модель поставщика), операционную систему (Microsoft
Windows, Apple macOS или Linux; версия и выпуск), сетевую конфигурацию (стати­
ческую или динамическую), учетные записи и авторизацию (сетевую или локал1,­
ную), обновления операционной системы (как они сделаны и одобрены, насколько
часто), безопасность (защита от атак, а также ограничения доступа и другие пробле­
мы) и ведение журшца (запись истории того, что эта машина делала).

Упр ажнения
1. В начале этой главы перечислены вопросы, которые важны для клиентов,
такие как локальность, надежность и производительность. Какие решения
затрагивают эти проблемы?
Глава 5 . Архитекrура рабочей станции 137

2. Рассмотрите архитектуру рабочей станции вашей организации. Как реше­


ния повлияли на вопросы, перечисленные в этой главе?
3. Каковы преимущества и недостатки взаимозаменяемых рабочих станций?
4. В чем преимущества помержки многих разных операционных систем? Ка­
ковы преимущества помержки только одной операционной системы?
5. В какой организации померживается ваша операционная система? Пере­
числите поставщиков, а также виды и версии операционных систем.
6. Перечислите различные параметры конфигурации сети и ситуации,
для которых они наиболее подходят.
7. Какие параметры сети в вашей организации распределяются через DHCP?
Как вы можете узнать точные настройки, которые, например, ваш ноутбук
получает при подключении через WiFi?
8. В этой главе содержатся предостережения по поводу настройки файлово­
го сервера для использования DHCP. Что происходит, если файловый сер­
вер настроен на использование DHCP и из-за сбоя питания файловый сервер
и сервер DHCP перезагружаются одновременно?
9. В чем разница между идентификацией, аутентификацией и авторизацией?
Свяжите эти понятия с процессом входа в систему виртуальной частной
сети (VPN), используя Facebook, или с доступом к платежной ведомости
через веб.
10. Что означает для рабочей станции отсутствие данных или состояния?
11. Какое хранилище используется для ноутбуков в вашей организации?
А для настольных компьютеров?
12. Что такое полное шифрование диска (FDE)? Использует ли его ваша рабо­
чая станция?
13. В чем преимущества автоматической установки обновлений операционной
системы перед ручной? С одобрением пользователя или без него?
14. Как обновления операционной системы обрабатываются в вашей органи­
зации?
15. Каковы плюсы и минусы использования белого списка антивирусов и при­
ложений?
16. Будет ли в будущем более актуальным использование антивирусных или
белых списков приложений?
17. Какие виды защиты применяются на рабочих станциях в вашей организации?
18. Почему потребительские антивирусные продукты включают красивые ани-
мации и подсказки?
19. Какую информацию можно найти в журналах рабочих станций компьютера?
20. Как ваша организация управляет журналами рабочих станций?
21. Почему журналы называются журналами? Изучите историю этой терми­
нологии и выясните, почему мы входим в наши компьютеры.
Глава 6

Стратегии управления
аппаратным о б еспечением
ра б очих станций

В этой главе рассматриваются три фундаментальные стратегии, связанные


с аппаратным обеспечением рабочих станций. Первая стратегия - предостав­
лять пользователям физические машины, такие как ноутбуки и настольные
компьютеры. Мы обсудим, как выбор поставщика продукта влияет на тип, ка­
чество и эффективность предоставляемых услуг. Вторая стратегия - это предо­
ставление инфраструктуры виртуальных рабочих столов (VDI - virtual desktop
infrastructure) или виртуальных машин, доступ к которым осуществляется с по­
мощью различных средств. Третья стратегия заключается в том, чтобы вооб­
ще не предоставлять пользователям рабочие станции. Использование своего
устройства (BYOD - bring your own device) предполагает предоставление до­
ступа к приложениям и услугам с использованием оборудования, которое уже
есть у клиентов.
Большинство крупных компаний сочетают эти стратегии, поскольку они ми­
грируют в направлении VDI и BYOD, чтобы снизить затраты и охватить мобиль­
ные вычисления.

6 .1. Физические рабочие станции


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

6.1.1. Ноутбук или насто11ьный ПК


Мы предполагаем, что читатели этой книги имеют базовые знания в области
аппаратного обеспечения и понимают разницу между ноутбуком и настольным
ПК. Однако некоторые различия не столь очевидны.
Настольные компьютеры обычно допускают больше расширений. У них есть
слоты для карт расширения и видеопроцессора, а также гнезда для дополнитель­
ной памяти. Они имеют внутреннее пространство для дополнительного диска.
Хотя в ноутбуках и настольных компьютерах есть порты для внешнего расшире­
ния (USB, Thunderbolt, eSATA), у настольных персональных компьютеров больше
площадь поверхности, на которой разработчики моrуг потенциально размещать
Глава 6. С1ратегии управления аппараniым обеспечением рабочих сrанций 139

такие порты. В результате даже модели с фиксированной конфигурацией


(устройства без слотов расширения) можно значительно расширить.
Ноутбуки, как правило, дороже, чем сопоставимые модели настольных ком­
пьютеров. Мобильность ноутбука требует, чтобы он был более прочным, потому
что люди могут их уронить, ударить или как-то иначе проявить небрежность при
работе с ними. Такая защита требует более сложного процесса проектирования
и тестирования, а также более надежных и, следовательно, более дорогих дета­
лей. Контракты на техобслуживание дороже из-за предполагаемой более высо­
кой скорости ремонта. Если ноутбук имеет проприетарные слоты расширения,
периферийные устройства, которые подключаются к этим слотам, будут дороже
из-за слабой конкуренции или полного ее отсутствия. Энергосберегающие функ­
ции, которые не нужны в настольной системе, повышают стоимость ноутбука.
Потребность в мобильности побуждает проектировщиков поддерживать энер­
госбережение и теплоотдачу, что приводит к выбору более медленных процес­
соров и устройств ввода-вывода. Таким образом, ноутбуки зачастую работают
медленнее, чем настольные компьютеры того же поколения.
Однако дополнительные расходы, связанные с использованием ноутбука, час­
то смягчаются другими факторами: устройства с фиксированной конфигурацией
имеют более низкие производственные затраты. Ноутбуки легче поддержи­
вать, потому что люди могут приносить их в службу поддержки, а не вызывать
IТ-специалиста к себе. Ноутбуки также хорошо подходят для компаний, которые
хотят применять динамические рассадки и иметь рабочие места для пула сотруд­
ников, а не стационарные столы, - в такой среде на каждом рабочем месте есть
только док-станция и люди приносят свои ноутбуки. Наконец дополнительные
затраты оправданы тем, что возможность принести ноутбук куда-либо имеет
свою ценность, особенно для людей, которые много путешествуют или поддер­
живают связь по телефону.
Большинство компаний, которые предоставляют своим сотрудникам физи­
ческое оборудование, обычно предлагают оба варианта. Одни позволяют менед­
жерам принимать решение вместо своих сотрудников, другие подходят к этому
вопросу более строго, основываясь на требованиях к работе человека.
Мы прогнозируем, что настольные компьютеры будут все больше заменять­
ся инфраструктурами виртуальных рабочих столов и тонкими клиентами. Из-за
портативности ноутбука мы ожидаем, что ноутбуки останутся подходящим вари­
антом на более продолжительное время, чем настольные персональные компью­
теры. Однако в конце концов большинство пользователей ноутбуков перейдут
на планшеты и другие мобильные устройства.

6.1.2. Выбор поставщика


При покупке оборудования существует большой выбор поставщиков. Органи­
зации могут привязаться к одному поставщику, выбирать фиксированный набор
поставщиков или, по сути, применять политику поддержки всех поставщиков.
Минимизируйте количество используемых поставщиков, чтобы снизить слож­
ность и затраты на поддержку.
Привязка к одному поставщику упрощает поддержку и облегчает получе­
ние скидок на оптовые закупки. Наличие нескольких поставщиков обеспечива­
ет ценовую конкуренцию, но связано с большей стоимостью поддержки. Одна­
ко дополнительные расходы на поддержку могут быть компенсированы за счет
140 Ч асть II. Управление парком рабочих станций

выигрыша в цене. Мы получим гораздо лучшие цены, просто сообщив одному


поставщику, что получаем котировки и от другого.
Организации, поддерживающие всех поставщиков, часто делают это из-за того,
что на самом деле или не имеют закупочной политики вообще, или имеют такую
политику, но не обеспечивают ее соблюдение, или приобретают каждую машину,
стремясь в каждом отдельном случае найти наилучшую начальную закупочную
цену вместо того, чтобы придерживаться дисциплинированной, устойчивой стра­
тегии управления общей стоимостью владения. Независимо от причин, это сип�ал
о том, что у IТ-подразделения не хватает планирования, дисциплины или поли­
тического влияния. Результатом является случайная и неравномерная поддержка
всех и превосходная поддержка конкретных поставщиков из-за непредсказуемых
обстоятельств, например из-за того, что системный администратор случайно ока­
зался экспертом по продуктам конкретного поставщика.
Прежде чем приступать к выбору поставщика, задокументируйте свои крите­
рии, оценки и методы выбора цены. Оценивая каждого поставщика, описывайте,
каким образом каждый производитель соответствует каждому критерию и как
этот рейтинг был достип�ут. Эrо поможет вам сосредоточиться на потребностях
вашей организации, а не отвлекаться на торги.

6.1.3. Выбор линии продукции


Большинство поставщиков имеют несколько производственных линий. Как
правило, вы найдете тех, кто подчеркивает низкую начальную стоимость, покуп­
ную цену и минимальную совокупную стоимость владения (ТСО -total cost of
ownership), и тех, кто делает акцент на производительности.
В зависимости от размера компании и потребностей людей внутри компании
может применяться одна или несколько линеек продукции. Например, инже­
нерной компании, возможно, придется заплатить премию за рабочие станции
для своих инженеров, но сосредоточиться на совокупной стоимости владения
для остальной компании. Для большинства компаний линейка продуктов, на ко­
торую они должны обратить внимание, - та, которая подчеркивает самую низ­
кую совокупную стоимость владения.

Самые низкие первоначальные затраты


Покупная цена - это стоимость, которую потребитель платит за приобрете­
ние продукта изначально и которая не включает в себя стоимость эксплуатации
устройства. Линия продукции, которая подчеркивает наименьшую начальную
стоимость или покупную цену, имеет низкую прибыль при первоначал1,ной про­
даже, потому что продавец балансирует ее с высокоприбыльными надстройками
и контрактами на обслуживание.
Самая низкая первоначальная покупная цена достигается за счет отказа
от функций, которые в долгосрочной перспективе сделают менее дорогостоящей
машину или сделают менее дорогостоящим управление многими машинами.
Например, фиксированная конфигурация снижает первоначальную цену покуп­
ки, но в будущем может потребоваться замена всей машины, что значительно
дороже, чем простое добавление другого жесткого диска.
Эта линейка продуктов также часто меняет набор деталей. Машины, выпу­
щенные в понедельник, могут иметь другой видеочип, чем машины, сделанные
Глава 6. Стратегии управления аппаратным обеспечением рабочих сrанций 141

во вторник, просто потому, что один поставщик изменил свою цену. Это позво­
ляет производителю корректировать колебания цен как можно быстрее, снижая
цену продажи. Клиенты не заметят изменения детали, если у них есть только
одна машина. Тем не менее любому, кто поддерживает парк машин, будет слож­
но и дорого поддерживать множество различных видеосистем; например.
Такие системы часто сложно или невозможно восстановить. Чтобы сэконо­
мит�, деньги, запасные части хранятся только год или два. Теневые продавцы мо­
гут вообще ничего не запасать, экономя еще больше денег.
Эти линейки продуктов часто называют "потребительскими" или "для малого
бизнеса", поскольку недостатки таких компромиссов обычно не будут ощущать­
ся в организациях с несколькими машинами.

Общая стоимость владения


Общая стоимость владения относится ко всем затратам, связанным с маши­
ной в течение всего срока ее службы. В нее входят начальная цена покупки, а так­
же сметная стоимость контрактов на обслуживание, техническое обслуживание
и ремонт для прогнозируемого срока службы устройства, как правило, три года.
Линейка продукции, которая снижает совокупную стоимость владения, дела­
ет это, сосредоточиваясь на проблемах, которые могут сэкономить деньги, когда
организация поддерживает большой парк машин. Эти производственные линии
часто называют "корпоративной линией" или "бизнес-линией".
Бизнес с большим парком может снизить свою совокупную стоимость владе­
ния, минимизируя различия в оборудовании. Это снижает затраты на обучение
П-отдела, а также уменьшает типы запасных частей, которые необходимо под­
держивать, и количество комбинаций операционных систем и драйверов, кото­
рые должны бып. проверены. Распаковать заплатки для операционных систем
гораздо дешевле, если их нужно тестировать с одним или двумя вариантами ап­
паратного обеспечения, а не с десятками.
В корпоративной линейке часто предоставляются гарантии того, как долго
будет доступна конкретная модель, при этом в течение этого времени будет на­
блюдап,ся очень небольшое "колебание деталей". Некоторые поставщики могут
предусмотреть шестимесячное предупреждение перед введением новых деталей
или окончанием срока службы старых деталей.
Корпоративная линейка машин разрабатывается исходя из предположения,
что внутренним IТ-отделам может потребоваться быстрый ремонт машин и их
возврат для гарантийного обслуживания. Разборка ноутбука для замены повреж­
денного жидкокристаллического экрана может быть длительным процессом, ус­
ложненным тесными конструкциями, которые используются из-за желания сэ­
кономить место. Предпринимать дополнительные меры для облегчения ремонта
ноутбука - дорогое занятие. Добавление механизмов для упрощения замены
жестких дисков увеличивает первоначальную покупную цену, но снижает стои­
мосп, ремонта.
Это менее важно для потребительских машин, которые ремонтируются
в местной компьютерной мастерской, взимающей почасовые ставки. Фактически
такая ремонтная мастерская извлекает выгоду из длительных процессов разбор­
ки и сборки.
Корпоративные линейки машин, как правило, поддерживают более старое
оборудование. Потребительский ноутбук может иметь один порт видеовыхода,
142 Часть 11. Управление парком рабочих станций

демонстрирующий новейшую технологию видеоразъема. Однако этого недоста­


точно для бизнес-пользователей, которым необходимо справляться с системами
видеоконференций, которые имеют входы VGA, вероятно, в течение десятилетий.
В корпоративную линейку будут включены дополнительные расходы, включая
как видеопорты, так и старые и новые последовательные порты, новые и старые.

Производитель ность
Линейку продукции, которая подчеркивает производительность, часто назы­
вают инженерной или высокопроизводительной. Она включает в себя функции,
необходимые для инженерных приложений, таких как автоматизированное про­
ектирование (CAD - computeг-aided design) и автоматизированная разработка
(САЕ - computeг-aided engineeгing), которые требуют высокопроизводительной
графики, векторной обработки и сложных вычислений.
Эrи модели предлагают самые быстрые новейшие процессоры, расширяемые
до больших объемов оперативной памяти, и имеют больше возможностей хра­
нения. Поставщики берут плату за новейшие процессоры и технологии, потому
что клиенты могут оправдать дополнительные затраты. Если инженеры могут ис­
пользовать более мелкие ячейки процессора, которые дают более точные резуль­
таты за счет своей гидродинамики и структурного моделирования, то продукция
в результате становится более эффективной и менее восприимчивой к поломкам
вследствие усталости. В результате такая продукция имеет более высокую репу­
тацию и повышенную долю на рынке, которая потенциально может стоить мил­
лионы долларов. По сравнению с этим дополнительная тысяча долларов на ра­
бочую станцию является очень небольшой затратой.

6.2. Инфраструктура виртуальных рабочих столов


Другой вариант архитектуры рабочей станции - инфраструктура виртуальных
рабочих столов (VDI virtual desktop infrastructure). Ее целью является превраще­
-

ние рабочих станций в централизованно управляемую сетевую службу для сниже­


ния административных и аппаратных затрат.
С помощью инфраструктуры виртуальных рабочих столов пользовательские
приложения запускаются на виртуальной машине (VM - virtual machine) в кла­
стере виртуальных серверов из любого узла сети. Пользователь взаимодействует
с виртуальной машиной, являясь "тонким клиентом". Тонкий клиент выглядит,
как очень маленький рабочий стол. У него есть главное устройство, к которому
подключаются монитор, клавиатура и мышь. Основной блок не имеет жестко­
го диска. Он управляет специализированной операционной системой, которая
просто подключается к виртуальной машине и, по сути, становится монитором,
клавиатурой и мышью.
Преимущества инфраструктуры виртуальных рабочих столов заключаются
в том, что они обеспечивают экономию за счет снижения стоимости аппарат­
ного обеспечения, а также упрощают управление. Проблема в развертывании
такой инфраструктуры связана с потребностями пользователей в доступе к не­
стандартным приложениям. Существуют также некоторые вариации моделей
инфраструктуры виртуальных рабочих столов с тонким клиентом, которые будут
описаны ниже в этом разделе.
Глава 6. Стратегии управления аппараrnым обеспечением рабочих сrанций 143

В условиях жесткой регламентированной среды, которая должна соответство­


вать таким стандартам, как Закон об унификации и учете в области медицин­
ского страхования (HIPAA - Health Insurance Portabllity and Accountabllity Act),
виртуальные рабочие столы предоставляют возможность более точного контроля
за доступом к информации. Они также препятствуют размещению конфиден­
циальной информации на незашифрованных съемных носителях, гарантируя,
что все взаимодействия данных выполняются на стороне сервера. Это еще одно
преимущество инфраструктуры виртуальных рабочих столов, кроме стоимости
и простоты управления.

6.2.1. Сниженные затраты


Тонкое клиентское оборудование стоит недорого, так как оно предназначено
для единственной цели - использования протокола удаленного доступа, такого
как Windows Terminal Services, VMWare Horizon или Citrix. Все аппаратные сред­
ства, не требуемые для этого, устраняются. Дальнейшая экономия достигается
за счет того, что мониторы, клавиатуры и мыши, к которым они подключаются,
являются стандартными товарными частями, такими же, как и на полноценных
персональных компьютерах.
Система виртуальных рабочих столов проще в управлении, поскольку тонкие
клиенты являются общими. Кто угодно может войти на один из них, и вирту­
альная машина будет выделена для этого человека в зависимости от его полно­
мочий. Инфраструктуры виртуальных рабочих столов часто используются эко­
номными пользователями, особенно там, где массовое развертывание означает,
что сбережения умножаются во много раз. Сами тонкие клиенты стоят намного
меньше полной рабочей станции и, как правило, не нуждаются в таком частом
обновлении.

6.2.2. Простота эксплуатации


Инфраструктура виртуального сервера допускает более экономически выгод­
ную модернизацию, поскольку не требует физического труда и посещения каж­
дого тонкого клиента. Обновление или расширение инфраструктуры виртуаль­
ного сервера приносит выгоду всем тонким клиентам.
Например, предположим, что изначально каждой виртуальной машине был
выделен один виртуальный процессор. Год спустя появились новые приложения,
которые требуют нескольких процессоров. В инфраструктуру виртуальных ма­
шин можно добавить дополнительные центральные процессоры и распределить
их между машинами. Теперь новые приложения работают быстрее без покупки
новых тонких клиентов. Такие модернизации оборудования также выигрывают
за счет масштаба.
В качестве другого примера предположим, что ста персональным компью­
терам необходим дополнительный терабайт памяти. Для этого потребовалось
бы сто отдельных жестких дисков. Работа по установке каждого жесткого дис­
ка обойдется дороже, чем сами жесткие диски. Если бы инфраструктура вирту­
альных машин использовала одно и то же хранилище, то это можно было бы
сделать путем размещения ста виртуальных дисков на жестком диске с большой
сетью SAN, построенной на более экономичных больших дисках. Это можно сде­
лать с помощью сценария PowerShell.
144 Часть 11. Управление парком рабочих станций

6.2.3 . Постоянная и непостоянная память


Первое, что сисrемный админисrратор должен учесrь при развертывании ин­
фрасrруктуры виртуальных рабочих сrолов, - должна ли она быть посrоянной.
Эrо решение оказывает значительное влияние как на опыт взаимодейсrвия, так
и на сrоимосrь и управляемосrь службы в целом.
При использовании непостоянной инфраструктуры виртуальных рабо­
чих столов (non-persistent VDI) виртуальный рабочий стол создается "с нуля",
используя сrандартный образ каждый раз, когда это необходимо. Непосrоянные
инфрасrруктуры не допускают насrройки.
При использовании постоянной инфраструктуры виртуальных рабочих
столов (persistent VDI) существует взаимно однозначное соответствие между
пользователями и виртуальными рабочими сrолами, а рабочий стол каждого
пользователя создается из отдельного образа диска. В конце каждого сеанса на­
сrройки пользователя сохраняются и появляются каждый раз при входе в сисrе­
му, как и на физической рабочей сrанции.
В средах, в которых пользователи имеют сrандартные потребносrи, оптималь­
ным выбором будет непосrоянная инфрасrруктура виртуальных рабочих сrолов.
В средах, в которых есrь опытные пользователи или многие пользователи нужда­
ются в несrандартных приложениях, посrоянная инфрасrруктура виртуальных
рабочих сrолов будет лучшим выбором. В некоторых средах может использо­
ваться сочетание обоих подходов.

Непостоянная инфраструктур а виртуальных рабочих столов


При использовании непосrоянной инфрасrруктуры виртуальных рабочих сrо­
лов виртуальные машины также являются общими. При каждой загрузке они на­
чинают с новой копии базового образа операционной сисrемы, часrо называемого
золотым образом. Все пользовательские файлы находятся в удаленном хранилище.
Если пользователь перезагружается, виртуальная машина воссоздается из новей­
шего золотого образа. Для отдельных компьютеров не требуется исправление или
обновление программного обеспечения. Обновление программного обеспечения
выполняется до золотого образа, и затем виртуальные машины перезагружаются,
чтобы получить новое обновление. Если пользователь случайно испортит опера­
ционную сисrему или вирус преодолеет защиту от вредоносного программного
обеспечения, то перезагрузка вернет машину в исходное сосrояние.
Непосrоянные инфрасrруктуры виртуальных рабочих сrолов часrо использу­
ются в колл-центрах или в любой ситуации, когда потребносrи пользователей
очень стандартизированы. Они также полезны для информационных киосков
и других ситуаций, в которых локальная поддержка минимальна и удобно иметь
возможносrь перезагрузить машину, чтобы вернуть ее в исходное сосrояние.
Преимущесrва непосrоянных инфрасrруктур виртуальных рабочих сrолов за­
ключаются в следующем.
• Админисrраторы моrут легко исправлять и обновлять образ - это нужно
делать только один раз и это относится к каждому компьютеру при следу­
ющей перезагрузке.
• Минимизируют требования к хранению и резервному копированию обра­
за операционной сисrемы.
Глава 6. Стратегии управления аппаратным обеспечением рабочих сrанций 145

• Упрощают развертывание общекорпоративных приложений для всех ко­


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

П остоянные инфраструктуры виртуальных рабочих столов


Постоянные инфраструктуры виртуальных рабоч:их столов допускают более
высокую степень персонализации. Тем не менее они также требуют более жест­
ких ресурсов и резервных копий, ч:ем непостоянные инфраструктуры виртуаль­
ных рабоч:их столов, поскольку каждый рабоч:ий стол работает с отдельного об­
раза диска, который необходимо сохранить и резервную копию которого необ­
ходимо создать.
В постоянной инфраструктуре виртуальных рабоч:их столов, организованной
по принципу "один к одному", пользовательские настройки сохраняются и по­
являются каждый раз при входе в систему. Эти типы настольных компьютеров
позволяют обеспеч:ивать более высокую степень персонализации, но им требует-
01 больше места для хранения и резервного копирования, ч:ем для постоянных
настольных компьютеров. Постоянные инфраструктуры виртуальных рабоч:их
столов имеют следую щие преимущества.
146 Часть II. Управление нарком рабочих стан ций

• Облегчают настройку. Конечные пользователи моrут персонализировать


постоянные рабочие столы и устанавливать собственное программное обе­
спечение, которое не требуется всем пользователям, и, возможно, имеет
дорогостоящее лицензирование.
• Обеспечивают более легкий переход для пользователей. Аспект настройки
постоянных рабочих столов, как правило, помогает пользователям более
легко осваиват1, инфраструктуру виртуальных рабочих столов.
• Их поддержка похожа на поддержку настольных систем. С точки зрения
поддержки конечных пользователей постоянная инфраструктура вирту­
альных рабочих столов не отличается от инфраструктуры физических ра­
бочих столов, что облегчает переход существующего персонала поддержки
на поддержку пользователей виртуальных рабочих столов.
• Для однозначного сопоставления образа диска с пользователем требуется
меньше перестройки рабочего стола, чем при переходе на единый стан­
дартны й образ с дополнительной виртуализацией приложений.
Недостатки постоянных инфраструктур виртуальных рабочих столов заключа­
ются в следующем.
• Требуются большие объемы памяти для хранения и резервного копиро­
вания данных. Все индивидуальные, настроенные образы дисков требуют
большей емкости памяти, чем один стандартный образ для непостоянных
инфраструктур виртуальных рабочих столов.
• Из-за управления образами возрастают накладные расходы на поддержку.
Подобно физическим рабочим столам разные образы операционной сис­
темы должны отдельно обновляться и исправляться. Поэтому постоянные
инфраструктуры виртуальных рабочих столов не выигрывают от того же
снижения вспомогательных накладных расходов, которые имеют непосто­
янные инфраструктуры.
• У них меньше преимуществ безопасности. Как и в случае с физическими
устройствам и, скомпрометированная постоянная и нфраструктура вир­
туальных рабочих столов остается под угрозой перезагрузки, потому что
(скомпрометированный) образ сохраняется.

В ариации
Помимо предоставления полноценных рабочих станций, и нфраструктуры
виртуальных рабочих столов моrут использоваться для предоставления отдель­
ных приложений. Хотя приложение выглядит так, будто оно установлено и за­
пущено на виртуальной машине пользователя, фактически оно работает на дру­
гой виртуальной машине, а созданные ею окна отображаются вместе с другими
окнами пользователя. В общем случае пользовател�, не сможет увидеть никакой
разницы. Это один из способов, которыми пользовательские приложения пре­
доставляются пользователям непостоянных инфраструктур виртуальных рабочих
столов.
Один из вариантов инфраструктуры виртуальных рабочих столов называется
толстый VDI-клиент (VDI thick client). Это эмулятор тонкого клиента, который
работает на обычном персональном компьютере. Представьте, что у пользователя
Глава 6. Стратеп�и управления аппараrnым обеспечением рабочих сrанций 147

уже есть компьютер, но ему нужно запустить одно приложение, досrупное из


службы приложений инфраструктуры вир�уальных рабочих столов. Пользователь
запускает на своей рабочей станции толстый клиент для досrупа к приложению,
избавляя от необходимости проходить какую-либо процедуру установки, исполь­
зовать любое локальное хранилище и т.д. В некоторых системах этот клиент рабо­
тает в браузере пользователя и поэтому не требует дополнительного программно­
го обеспечения, хотя и с некоторыми нарушениями функциональности.
Толстые клиенты предоставляют пользователям досrуп к приложениям, ко­
торые в противном случае были бы не совместимы с их рабочими станциями.
Например, можно получить досrуп к приложениям, которые не совместимы
с операционной системой рабочей станции или конфлик�уют с другими уста­
новленными приложениями.
Существуют также преимущества безопасности. Например, может быть слож­
но получить разрешение на установку приложений на компьютерах. Однако,
если толстое клиентское приложение было одобрено, пользователь может затем
безопасно получить дос�уп к любым приложениям, предоставленным VDI. В це­
лом толстому клиен�у VDI можно доверять, поскольку он работает в защищен­
ном контейнере, обычно в среде выполнения Java, которая проверена и одобрена
группой безопасности организации.
.. :

Пример: VDI для ненадежного проrраммноrо обеспечения


Однажды в одной крупной консалтинговой фирме системный администра­
тор развернул свое рабочее место на рабочем месте клиента. Клиент предо­
ставил ему рабочую станцию для использования, но ограничил программное
обеспечение, которое может быть установлено. Системный администратор
не смог установить программное обеспечение для ведения табеля рабочего
времени, необходимого для того, чтобы компания оплатила его рабо�у. Тем
не менее клиентские рабочие станции поддерживали толстый клиент VDI.
Системный администратор смог получить надежный доступ к программно­
му обеспечению табелирования в инфраструк�уре вир�уальных рабочих сто­
лов, не нарушая политику ограничения программного обеспечения клиента.
Клиент одобрил этот вариант использования, потому что доверял безопас­
ности толстого клиента VDI.

6.3. Использование собственных устр ойств


Использование собственных устройств (BYOD) - это модель обслуживания,
при которой пользователи приносят на рабо�у собственное аппаратное устрой­
ство, а не используют то, которое предоставляет их работодатель. Например,
люди мoryr использовать мобильное устройство, например телефон Andгoid или
Apple iPad, и запускать на нем корпоративные приложения.
Это радикальный отход от того, как в прошлом работали П-отделы. Обычно
IТ-отдел оценивает устройства и сообщает своим пользователям, что они мoryr
и будут использовать. Принятие стратегии, когда пользователи предоставляют
свое оборудование, а IТ-подразделение должно понять, как их поддерживать,
требует перестройки.
148 Часть 11. Упрапление парком рабочих станций

6.3.1. Стратеrии
Принимая стратегию BYOD-only (использование исключительно собственных
устройств), IТ-организация не предоставляет аппаратное обеспечение и требует
от пользователей использовать свои устройства. Пользователи BYOD-only обыч­
но представляют собой определенную группу, например людей, участвующих
в конкретной программе или краткосрочном проекте.
Например, учащиеся колледжа, заключившие контракт на шестинедельную
кампанию, мoryr нуждаться только в доступе к электронной почте и приложе­
нию для конкретной задачи, и обычно у них уже есть мобильное устройство.
Стратегия BYOD-only позволяет им быть продуктивными, не увеличивая при
этом значительную нагрузку для IТ-организации.
В стратегии смешанной модели BYOD (BYOD mixed model strategy) IТ-органи­
зация поставляет рабочие станции, но также разрешает модель BYOD. Часто это
повышает производительность или является способом предоставления мобиль-
1юго доступа. Компании мoryr поддерживать мобильные устройства, принадле­
жащие корпорациям, для определенных людей (как правило, продавцов и ру­
ководителей) и обнаружить, что поддержка всех личных устройств влечет лишь
небольшую дополнительную плату. Кроме того, многие компании считают, что
если они не поддерживают какую-то разновидность стратегии BYOD, то пользо­
ватели найдут импро1тзированные решения, которые дадут им доступ к мобиль­
ному телефону, который они захотят. К сожалению, эти обходные пути никог­
да не бывают такими же безопасными, как правильно поддерживаемая служба
BYOD. Таким образом, предоставление услуг BYOD повышает безопасность.
Упрощенная стратегия BYOD (BYOD-lite strategy) по:шоляет получить до­
ступ к небольшому количеству конкретных приложений, возможно, состоящему
только из зарегистрированных устройств, изготовленных утвержденными постав­
щиками. Например, организация может предоставить доступ к основному при­
ложению, скажем, электронной почте, календарю и корпоративной телефонной
книге, но не к чему-либо еще.
Принятие подхода BYOD неизбежно, и компаниям необходимо четко опреде­
лить стратегию поддержки. Для большинства компаний правильным выбором
является смешанная модель BYOD. Сотрудники используют ресурсы компании,
такие как тонкий клиент VDI или физическую рабочую станцию, когда они ра­
ботают на своем рабочем месте, и мoryr получить доступ к большинству прило­
жений со своих мобил1,ных устройств в другое время. Для некоторых отраслей,
таких как здравоохранение и банковское дело, в которых конфиденциальность
данных и регулирование являются важными темами, более подходящей может
оказаться стратегия BYOD-lite, и конечные пользователи мoryr лучше понять не­
обходимость более ограничешюго доступа.

6.3.2. Плюсы и минусы


Стратегия BYOD приносит пользу пользователям, поскольку они, как прави­
ло, чувствуют себя комфортно с их текущим устройством и находят утомитель­
ным носить с собой второе устройство для работы.
Стратегия BYOD приносит компании поль:iу, улучшая производительность
работы ее сотрудников и позволяя ей не брать на себя полную ответственность
:ia аппаратную поддержку. Экономия достигается за счет отказа от поставок
аппаратного обеспечения и тем более за счет отсутствия необходимости его
Глава 6. Стратегии управления аппараrnым обеспечением рабочих станций 149

поддержки. Стоимость поддержки часто превышает стоимость покупки обору­


дования, тем более что мобильные устройства часто бывают дешевыми. Страте­
rия BYOD также приносит пользу компании, потому что, коrда сотрудники име­
ют свободный доступ к своей работе, они становятся более мобильными, доступ­
ными и будут работать больше, даже не осознавая этоrо.
Однако стоимость поддержки возрастает из-за дополнительной сложности, ха­
рактерной для обслуживания широкоrо круrа моделей и устройств. Поддержка не­
скольких брендов и моделей является затруднительной и может потребовать рас­
ширения числа необходимых инженеров поддержки. Дешевле купить сотруднику
поддерживаемое устройство, чем нанять инженера в службу технической поддерж­
ки на неделю, чтобы понять, как заставить работать одно необычное устройство.
Эrу сложность можно смяrчить путем принятия классов поддержки. Перво­
классные модели поддерживаются полностью. Если приложение не работает
на первоклассных моделях, оно считается ошибкой - так же, как если бы прило­
жение не работало на рабочей станции, выпущенной компанией. Модели второrо
класса порождают некоторые хорошо известные проблемы и некоторые прило­
жения на них не работают. Устройства третьеrо класса не имеют rарантированной
поддержки или переходят на самообслуживание. Сотрудники службы поддержки
оrраничивают время, которое они моrуг потратить, пытаясь исправить проблему.

6. 3 . 3 . Безопасность
Стратегия ВУОО вызывает множество проблем с безопасностью. Защищено
ли устройство от вредоносных проrрамм, клавиатурных шпионских проrрамм
и перехватчиков паролей? Что делать, если устройство украдено? П роrрамм­
ное обеспечение управления мобильными устройствами (МОМ moblle device
-

mana gement) позволяет орrанизации обеспечивать бе:юпасность и управление


ВУОО-устройствами. Типичные функции включают в себя возможность запре­
тить доступ, если не используется утвержденное программное обеспечение
для защиты от вредоносных приложений, выполнять сквозное шифрование во
всех сеансах связи и дистанционно стирать устройства (или только данные, нахо­
дящиеся в собственности корпорации) в случае кражи или увольнения сотруд­
ника. Программное обеспечение МОМ также может отклонить доступ, если не
включены определенные параметры безопасности. Например, может потребо­
ваться РIN-код разблокировки или недавний сертификат безопасности.
Системы МОМ часто включают в себя своеrо рода толстый клиент VOI, кото­
рый разрешает доступ к приложению, как описано ранее.
Стратеrия ВУОО может быть причиной утечки данных. Не только устройство,
но и программное обеспечение на этих устройствах физически не контролиру­
ется компанией. По этой причине важно оценить риски утечки данных, а также
определить и применить процесс идентификации, оценки и управления риска­
ми. Например, определить, какие типы данных моrуг храниться на мобильных
устройствах, а какие моrуг быть только на устройствах с МОМ.

6.3.4. Дополнительные расходы


Мобильные устройства с планами сотовой rолосовой связи и передачи данных
моrуг принести большие расходы. Часто компании возмещают сотрудникам их
счета за мобильную связь с ежемесячными лимитами. Требование к сотрудникам
заполнять форму возмещения и сканировать свои мобильные счета ежемесячно
150 Часть 11. Управление парком рабочих станций

в лучшем случае утомительно, а в худшем является пустой тратой времени.


Обычно в конечном итоге лучше добавить фиксированную сумму к зарплате.
Планы ВУОО должны также учитывать воздействие на сеть. Как правило, все
мобильные устройства подключаются к компании через сеть VPN. Если текущая
сеть VPN почти перегружена, добавление сотен новых мобильных устройств вы­
ведет ее из строя. Moryr потребоваться дополнительная пропускная способность
и дополнительное оборудование VPN.

6.3.5. Удобство использования


И наконец самое главное - удобство работы конечного пользователя. Для
того чтобы система ВУОО была принята конечными пользователями, она должна
быть удобной. Удобства использования важнее всех остальных факторов. Исто­
рически люди терпели корпоративные приложения с плохо спланированными
пользовательскими интерфейсами и уродливыми цветовыми схемами, потому
что им было сказано их использовать (и заплачено за это). IТ-подразделениям
не нужно было уделять пользователям столько внимания. Для сравнения при
создании бытовых устройств на стиле и дизайне делается гораздо больший ак­
цент. Например, дизайнеры iPhone посвятили мноrо времени взаимодействию
различных частей и стремились исправить все мел кие детали, обеспечивая то,
что стало известным под названием "дизайн, качество сборки и отделки". Это
повышает ожидания пользователей относительно качества и удобства использо­
вания. В отличие от прошлого, когда IТ-отделы рассказывали клиентам, что они
будут использовать, сотрудники, использующие принцип ВУОО, имеют больше
возможностей отказаться, если им не нравится то, что было предложено.
Мобильные устройсrва - это будущее информационных технологий, а ВУОО -
их большая часть. По мере того как мобильные устройства становятся все более и бо­
лее мощными и лучше функционирующими, они используют все больше и больше
вариантов использования рабочих станций. Благодаря продуманному планирова­
нию и дисциплинированным политикам безопасности ВУОО может стать стратеги­
ческой частью предоставления услуг конечным пользователям.

Катастрофа, связа1П1ая с использованием MDM


Многие стратегии развертывания ВУОО были разрушены неуклюжими си­
стемами, требующими от пользователей неоднократного ввода паролей.
Провалившиеся проекты оставляют после себя неприятные чувства от обще­
ния между сотрудниками и их IТ-отделом.
При работе с одной программой МОМ человек, использующий Facebook, ко­
торый хотел приостановить работу и проверить рабочую корреспонденцию,
должен был выйти из Facebook, выйти из личной зоны устройства, войти
в рабочую зону и войти на электронную почту. Чтобы вернуться на Facebook,
этот процесс необходимо было повторить в обратном порядке. Единствен­
ным, что еще более шокировало, чем этот ужасный рабочий процесс МДМ,
было то, что компании покупали эту программу.
Если что-то и предотвратит принятие стратегии ВУОО, то это, к сожалению,
сами продавцы МОМ, многие из которых, похоже, не понимают, что воспри­
ятие их продукции зависит от удобства использования.
Глава 6. СтратеI"ии управления аппаратным обеспечением рабочих сrанций 151

6.4. Резюме
Существуют три основные стратегии обеспечения рабочих станций для поль­
зователей.
Традиционная стратегия :3аключается в предоставлении обычных ноутбуков
и/или настольных компьютеров. Рекомендации по выбору аппаратных средств
для рабочих станций :\ависят от того, идет ли речь о поставке настольных ком­
пьютеров или ноутбуков. Продавцы обычно имеют несколько линеек продук­
ции. Линейка потребителей, или малого бизнеса, подчеркивает первоначальную
покупную цену. Корпоративная, или бизнес-линейка, подчеркивает достижение
лучших показателей общей стоимости владения и управления. Линейка высоко­
производительной продукции подчеркивает отличные параметры ее производи­
тельности.
Стратегия VDI использует виртуальные машины в качестве рабочих станций.
Затем пользователи получают доступ к виртуальным машинам через тонкие
клиенты (оборудование, которое состоит из дисплея, клавиатуры и мыши) или
толстые клиенты (программное обеспечение, которое работает на существующей
рабочей станции или мобильном устройстве).
Стратегия использования собственных устройств (BYOD) использует личные
мобильные устройства людей, но дает им доступ к корпоративным приложе­
ниям и ресурсам . Это делается с помощью безопасного SSL-доступа к веб-сай­
там и виртуальным частям или программного обеспечения для толстого клиен­
та VDI.
Какой бы ни была стратегия, качество полученного пользовательского опы­
та можно описать с точки зрения ключевых проблем, описанных в предыдущей
главе: локал1,носп,, надежность, производительность, удобство использования
и актуальность.

Упр ажн ения


1. Каковы три основные стратегии предоставления рабочих станций пользо­
вателям?
2. С ноутбуком можно пойти куда угодно. Почему мы вообще покупаем на­
стольные компьютеры?
3. Я весь день сижу за своим столом, и все мои коллеги тоже. Зачем мне пе­
реходить на ноутбук?
4. Как поставщики обычно дифференцируют свои линейки продукции?
5. Одни линейки продукции ориентированы на наименьшую начальную сто­
имость, в то 11ремя как другие ориентированы на совокупную стоимость
владения. Сравните два типа линеек продукции.
6. Перечислите поста11щиков разных рабочих станций, которые используют­
ся в вашей среде. Считаете ли вы, что их слишком много? Какие преиму­
щества и проблемы во:шикают при увеличении количества поставщиков,
а также при их уменьшении?
7. Назовите три функции, которые повышают совокупную стоимость владе­
ния. Как мы узнаем в момент покупки, стоит ли она своей цены? Как мы
позже оценим, была ли достигнута цель?
152 Часть 11. Управление парком рабочих станций

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


генеральный директор хочет сэкономить деньги, покупая рабочие станции
потребительской линейки, потому что первоначальная цена покупки очень
привлекательна. Как вы могли бы отговорить своего генерального директо­
ра от этого плохого решения?
9. Привязка к одному поставщику упрощает получение скидок для оптовых
закупок. Почему?
10. Что такое стратегия VDI и как она работает? Что такое опыт использования?
11. Что такое BYOD и когда следует применять эту стратегию?
12. Какая стратегия или стратегии используются в вашей организации? Како­
вы будут преимущества перехода на другие стратегии? Какие из этих льгот
будут применяться к вам или к сотруднику, которого вы знаете?
13. Рассмотрите вопросы, указанные в главе 5 (локальность, надежность и т.д.).
По каждой из трех стратегий, определенных в этой главе, укажите, как они
помогают или препятствуют вашей способности позитивно решать каж­
дую из перечисленных проблем?
14. Какая стратегия используется для вашей рабочей станции в вашей органи­
зации? Каковы плюсы и минусы?
15. Учитывая все различные варианты, описанные в этой главе и в главе 5,
спроектируйте архитектуру настольных компьютеров, которая подходит
для компании из 20 сотрудников.
16. Повторите упражнение 15, но предположите, что в компании работает ты­
сяча сотрудников.
17. Повторите упражнение 15, но предположите, что у компании есть колл­
центр с тысячей сотрудников, сидящих в офисе, и с двумя тысячами служа­
щих, работающих дома.
Глава 7
Жизненный цикл
ра б очей станции

В этой главе приведен обзор процессов установки и обслуживания прог­


раммного обеспечения, которое выполняется на наших компьютерах. Первым
программным продуктом, необходимым компьютеру, является его операцион­
ная система. Она должна быть инсталлирована, а затем настроена. После это­
го устанавливаются приложения. Как операционная система, так и прикладное
программное обеспечение в конечном счете необходимо будет обновить или
исправить, поскольку новые версии добавляют функции, исправляют ошибки
и перекрывают обнаруженные слабые места в системе безопасности. Настрой­
ки конфиrурации должны постоянно уточняться из-за меняющихся требований.
Файлы и конфиrурации моrут быть повреждены и нуждаться в ремонте. Иногда
нам нужно стереть и переустановить машину с той же самой или новой опера­
ционной системой. Наконец, когда машина выведена из эксплуатации, перед ее
выключением операционную систему и ее файлы необходимо удалить. Все эти
шаги можно выполнить вручную или с помощью автоматизации. Как вы уже
догадались, мы выступаем за автоматизацию.
Каждая новая машина должна начинаться с определенного исправного состо­
яния. В конечном счете операционная система и конфиrурация будут ухудшать­
ся самостоятельно. Если каждая машина не будет запущена из одного и того же
состояния, то процесс ухудшения усилится.
Активное управление операционной системой и жизненным циклом машины
является важной частью работы системного администратора. Некоторые органи­
зации выбирают пассивное управление: операционная система, поставляемая
с машиной, поддерживается до тех пор, пока машина не выйдет из строя. Эго
кошмар, но очень распространенный. В таких условиях минимальные изменения
в парке сопряжены с огромным объемом работы. Без автоматизации эти задачи
будут задерживаться или игнорироваться одновременно, что приводит к появле­
нию новых проблем.

7. 1 . Жизненный цикл машины


Машины рождаются, живут и умирают. Этот жизненный цикл рассмотрен
в статье Реми Эварда (Remy Evaгd) "An Analysis of Unix System Configuration"
(Evard 1997), диаграмма из которой приведена на рис. 7.1 .
154 Часп, 1 1 . Управление нарком рабочих станций

Сборкау
l j

Рис. 7 .1 . Жшнен н ы i1. ц111 с1 мт11ин 111 и ее операц 1юнноi1 с11сте.мы по Эварду

Диаграмма отображает пяп, состояний: новое, чистое, сконфигурированное,


неизвестное и отключенное.
• Новое: совершенно новая, ненастроенная машина
• Чистое: компьютер, на котором инсталлиро11ана операционная система,
но не выполнена ее локализация.
• Сконфигурированное: правильно сконфигурированная и работоспособ-
ная среда.
• Неизвестное: неверно настроенный или устаревший компьютер.
• Отключенное: машина, которая была удалена и отключена.
Существует много способо11 переводить машины из одного состояния жи:шен­
ного цикла в другое. В большинстве организаций процессы сборки и инициа.ли­
зации машины обычно совмещаются. Это приводит к тому, что операционная
среда загружается и сразу переводится в рабочее состояние. Энтро11ия это -

ухудшение или нежелател1,ные изменения. Она оставляет компьютер в неизвест­


ном состоянии, которое фиксируется процессом отладки. Обновления происхо­
дят со временем, часто в виде исправлений и обновлений системы безопасности.
Иногда имеет смысл стирать и перезагружать компьютер, потому что пришло
время для серьезного обновления операционной системы, система должна быть
воссоздана с новой целью или сильная энтропия не оставила вам другого выхода.
Происходит процесс восстанов.ления, данные на машине стираются и она переза­
гружается, чтобы вернуться в чистое состояние, а затем инициализируется, что­
бы перейти в сконфигурированное состояние.
Эти процессы повторяются в течение месяцев и лет. Наконец машина устаре­
вает и с11исывается (retired). В качестве альтернативы она может умереть трагичес­
кой смерп,ю или в соответствии с моделью перейти в отключенное состояние .
Что мы можем извлечь из этой диаграммы? Во-первых, следует понять, что
существуют различные состояния и переходы. Наша команда должна иметь
Глава 7. Жизненный цикл рабочей станци и 155

процесс для каждого перехода. Мы планируем усrановить время для инсrалля­


ции, смириться с тем, что усrройсrва рано или поздно выходят из сrроя и требу­
ют ремонта и т.д. Мы не ведем себя так, будто каждый ремонт - это неожидан­
носrь. Вмесrо этого мы насrраиваем процесс ремонта и, возможно, организовы­
ваем целую ремонтную службу, если этого требует объем работ. Все это требует
планирования, кадрового обеспечения и других ресурсов.
Во-вторых, отметим, что, хотя сущесrвует множесrво состояний, компьютер
можно использовать только в сконфигурированном сосrоянии. Мы хотим макси­
мально увеличить время, которое машина находится именно в этом состоянии.
Большинсrво других процессов связаны с переводом компьютера в сконфигури­
рованное состояние или его возвратом в это сосrояние. Поэтому процессы на­
сrройки и восстановления должны быть бысrрыми, эффективными и автомати­
зированными.
Чтобы продлить время, проведенное в сконфигурированном сосrоянии, мы
должны гарантировать, что операционная сисrема будет деградировать как мож­
но медленнее. Дизайнерские решения производителя операционной сисrемы
оказывают на это самое большое влияние. Одни операционные сисrемы создают
подкаталог для каждого приложения и инсrаллируют в нем все связанные фай­
лы, тем самым консолидируя влияние усrановки на энтропию. Другие операци­
онные системы разбрасывают файлы приложения повсюду: основной выполняе­
мый файл - в одном месrе, библиотеки - в другом, файлы данных - в третьем
и т.д. Это затрудняет выяснение, какие файлы являются часrью какого пакета.
В часrносrи, печальную извесrносrь в этой обласrи получила операционная си­
стема Microsoft Windows. Напротив, поскольку система Unix предосrавляет стро­
гие разрешения для каталогов, пользовательские приложения не могут ухудшить
целосrносrь операционной сисrемы.
Как обсуждалось в главе 5, решения, принятые сисrемным админисrратором,
играют большую роль в этом процессе и могут усилить или ослабить целост­
ность операционной сисrемы. Имеется ли определенное месrо для инсrалляции
посторонних приложений? Получил ли пользователь корневой досrуп или до­
сrуп администратора? Разработал ли системный админисrратор способ, с помо­
щью которого пользователи могут выполнять определенные админисrративные
задачи, не имея высшего уровня корневого досrупа? Сисrемные админисrраторы
должны найти баланс между предосrавлением пользователям полного досrупа
и ограничениями. Это решение влияет на скоросrь, с которой будет деградиро­
вать операционная сисrема. Мудрый человек однажды сказал: "Человеку свой­
сrвенно ошибаться, но, чтобы дейсrвительно все испортить, нужен пароль root " .
Ручная инсrалляция подвержена ошибкам. Если во время инсrалляции будут
допущены ошибки, деградация узла сети начнется с самого начала его сущесrво­
вания. Однако, если процесс инсrалляции полносrью автоматизирован, то новые
рабочие станции будут разворачиваться правильно.
Повторная инсталляция - процесс восстановления - похожа на инсталля­
цию, за исключением того, что потенциально придется переносить старые дан­
ные и приложения. Как описано в разделе 5.6, повторная инсталляция выполня­
ется проще, если данные не хранятся локально на машине, или л юбые данные,
хранящиеся локально, являются копией данных, хранящихся в другом месrе. Эта
тема будет рассмотрена более подробно в главе 33.
156 Ч а сть 11. Управление парком рабочих станций

Наконец, эта модель подтверждает, что машины в конечном счете списывают­


ся. Машины не работают вечно. Со списыванием машины связаны разные задачи.
Как и в случае повторной инсталляции, некоторые данные и приложения долж­
ны переноситься на заменяющий компьютер или сохраняться на мап�итной ленте
для дальнейшего использования; иначе они будут потеряны в песках времени.
Для того чтобы правильно организовать управление операционной системой,
мы должны предусмотреть процедуры для обработки каждого из этих состоя­
ний. Эrи процедуры могут быть произвольными и импровизированными, если
организация небольшая, но профессиональный системный администратор дол­
жен организовать формальные процессы, которые реализуются средствами авто­
матизации.

7.2. Инсталляция операционной системы


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

7.3. Конфигурирование оп ерационной системы


После инсталляции необходимо настроить многие подсистемы и компонен­
ты. Конкретные настройки со временем могут меняться, поэтому нам нужен спо­
соб как для первоначальных изменений конфигурации, так и для их обновления.
Существует множество способов создания и распространения таких конфи­
гураций. В этой главе рассматриваются системы управления конфигурацией
(СМ - configuгation management), объекты групповой политики (GPO - group
police objects) и некоторые трюки, которые можно делать с протоколом DHCP.
Этот раздел заканчивается описанием распространенной практики, которую мы
не рекомендуем.

7.3.1. Системы управления конфигурацией


Как описано в главе 4, системы управления конфигурацией используют
специализированные языки программирования, которые позволяют описывать
детали того, как должна выглядеть правильно сконфигурированная система,
называемая желаемым состоянием (desired state). Система управления кон­
фигурацией считывает это описание и вносит необходимые изменения, чтобы
машина соответствовала желаемому состоянию. Если система уже соответству­
ет требованиям, то изменений не будет. Если только несколько параметров от­
клонились от нормы, будут сделаны лишь минимальные требуемые изменения.
По этой причине эти системы можно использовать для настройки только что
Глава 7. Жизненный цикл рабочей станции 157

инсталлированной машины или периодически запускать ее для уменьшения эн­


тропии по мере ее появления, а также для перевода машин, которые дрейфуют
в неu.Jвестное состояние, обратно в сконфигурированное. Позднее, если конфи�:ура­
ция должна измениться, обновление СМ-кода приведет к соответствующим из­
менениям на машине.
Системы управления конфи�:урацией обычно представляют собой совокупность
классов, подобно объектно-ориентированным языкам. Таким образом, вы можете
определить один класс, описывающий базовую конфи�:урацию системы CentOS,
а другой - DeЬian. Остальные классы мо�:ут описывать настройку НТТР-сервера
Apache НТТР, DНСР-сервера ISC или другого сервера приложений. Указав, что
конкре111ый хост запускает CentOS и является веб-сервером Apache НТТР, система
управления конфи�:урацией будет делать все правильно. Другой хост может быть
определен как хост DeЬian, который также является DНСР-сервером.
Такие системы разрешают создавать подклассы на основе других классов.
Например, можно определить сервер для блога с помощью класса веб-сервера,
в который внесены дополнительные изменения, такие как программное обеспе­
чение для ведения блога. Этот код повторно используется для построения более
сложных систем.
Класс, определяющий конфи�:урацию компьютера CentOS, может включать
н себя информацию о том, что все машины CentOS настроены так, чтобы указы­
вап, на конкретный сервер NTP для синхронизации времени. Если мы нуждаем­
ся в них, чтобы указать на другой сервер NTP, простое изменение этого класса
приведет к изменению всех компьютеров CentOS. Это позволяет нам совершать
массовые изменения с минимальными усилиями.
Системы управления конфи�:урацией являются предпочтительным методом
распределения изменений из-за высокой степени контроля, которую они обеспе­
чивают.

Предоставление пользователям контроля над настройками


Компания Google разработала высокоавтоматизированную систему для инстал- ·

ляции, настройки и обновления macOS. Она обеспечивает многочисленные на­


стройки безопасности. Некоторые из этих настроек непопулярны у небольшого
числа пользователей. Компания Google разработала систему, позволяющую
пользователям отключать определенные параметры безопасности для каждого
компьютера. Система предоставляет программные кнопки или переключате­
ли, которые пользователи мо�:ут настраивать. Например, из-за многих проблем
с безопасностью, интерфейсы Firewire по умолчанию отключены, но есть кноп­
ка, которая будет их активизировать. Без этой кнопки люди, которые хотели ·

бы подключить периферийные устройства Firewire, могли найти способы по­


дорвать настройки безопасности, возможно, в ущерб общей безопасности ма- •

шины. Благодаря этой кнопке пользователи получают то, что хотят, а группа ·

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


Если большое количество людей отменяет определенные параметры безопасно­
сти, это полезная информация. Группа безопасности знает, какие пользователи
должны проводить опрос, чтобы лучше понимать их потребности и более точ­
но определять пути достижения целей пользователей.
158 Ч асть 11. Управление парком рабочих станций

7.3.2. Объекты групповой политики Microsoft


Системы Microsoft Windows используют объекты групповой политики
для внесения изменений или настройки политик для разных машин и пользо­
вателей. Поскольку они не такие сложные, как системы управления полной кон­
фигурацией, объекты GPO интегрированы в систему Windows так, что их очень
легко реализовать.
Объект групповой политики определяет некоторые разрешения или настрой­
ки для определения, хранящегося в службе каталогов ActiveDirectory. Объект
групповой политики может применяться к группам компьютеров или пользо­
вателей. Предположим, что есть группа пользователей, у которых должна быть
немного более ограниченная среда. Существует параметр групповой политики,
который отключает изменения на панели задач и в меню Пуск. Этот параметр
можно применить к пользователям из этой группы. Объект групповой полити­
ки можно также применить к конкретным машинам . Например, есть параметр
групповой политики, который отключает пункт меню выключения для неад­
министративных пользователей. Этот параметр объекта групповой политики
может быть применен к любой общей машине, поскольку мы не хотим, чтобы
пользователь случайно выключал машину, пока другие ее используют. Объекты
групповой политики также могут определять политики доступа к принтеру, рас­
писание обновлений и многие другие параметры.
Хотя объекты групповой политики, как правило, вводятся вручную с исполь­
зованием средств администрирования на основе графического пользовательского
интерфейса Microsoft Windows, их также можно создавать и распространять че­
рез системы управления конфигурацией, тем самы м получая лучшее из обеих
возможностей.

7.3.3. Конфигурация DHCP


Многие параметры сети можно контролировать с помощью протокола DHCP.
Как описано в разделе 5.4, это часто более полезно для рабочих станций, чем
для серверов. Например, протокол DHCP может использоваться для настройки
DNS-cepвepa, который использует компьютер. Если вы выводите из эксплуатации
один DNS-cepвep и заменяете его другим, настройте IР-адрес нового DNS-cepвepa
в конфигурации DНСР-сервера. Новая конфигурация будет распространена сре­
ди всех новых клиентов. При продлении аренды существующие клиенты будут
получать новую информацию. В зависимости от того, как часто клиенты обнов­
ляют свои договоры аренды, на все машины могут уходить часы, дни или недели.
Поэтому как старые, так и новые DNS-cepвepы должны будут оставаться актив­
ными до тех пор, пока последний клиент DHCP не возобновит свою аренду и не
увидит изменения.
Протокол DHCP и меет много преимуществ. Во-первых, он может управлять
машинами, к которым у вас нет административного доступа. Большинство опе­
рационных систем по умолчанию используют протокол DHCP для управления
настройками NIC и DNS, а также другими сетевыми параметрами. Поэтому
даже гостевая машина, над которой у вас нет контроля, будет соблюдать настрой­
ки, которые вы предоставляете с вашего DНСР-сервера.
У протокола DHCP есть и недостатки. Он контролирует лишь несколько пре­
допределенных настроек, почти все связанные с сетью. Не каждый компьютер
Глава 7. Жизненный цикл рабочей станции 159

в вашей сети будет использовать протокол DHCP, поэтому вам придется выпол­
нить любое изменение дважды: для хостов DHCP и для всех остальных. Качество
реализации DНСР-клиента также различается. Рабочие станции и серверы обыч­
но имеют тщательно проверенные полнофункциональные реализации, в то вре­
мя как все другие устройства реализованы в минимальном объеме и с ошибками.
Некоторые встроенные устройства игнорируют измененные параметры при воз­
обновлении аренды, что препятствует попыткам внесения глобальных изменений
через DHCP. Многие телефоны с голосовой связью по протоколу IP (VoIP) имеют
весьма реалистичные реализации протокола DHCP, которые отключаются, если
они посылают необязательные параметры, которые к ним не относятся. Одна­
ко самой большой проблемой при распространении изменений через протокол
DHCP является отсутствие положительной обратной связи. Трудно определить,
какие клиенты получили обновление, какие нет, а какие просто исчезли. Вам
необходимо дождаться истечения всего срока аренды, чтобы убедиться, что все
динамические клиенты получили обновление. Однако протокол DHCP также до­
пускает статическую аренду, у которой либо нет даты истечения срока аренды,
либо предусмотрен очень длинный срок аренды. Машины со статической кон­
фигурацией DHCP часто получают новые настройки только после перезагрузки.

7.3.4. Установка пакета


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

7.4. Обновление системного пр ограммного


обеспечения и прило жений
Было бы неплохо, если бы работа системного администратора была закончена
после загрузки операционной системы и приложений. К сожалению, со време­
нем обнаруживаются новые ошибки и слабые места в безопасности. Кроме того,
становятся доступными новые приложения.
Для выполнения всех этих задач требуются обновления программного обеспе­
чения. Кто-то должен позаботиться о них, и этот кто-то - вы. Однако не бес­
покойтесь: вам не нужно тратить все свое время на обновление. Как и процесс
инсталляции, обновления могут и должны быть автоматизированы.
160 Часть 11. Управление парком рабочих станций

Системы обновления программного обеспечения должны быть достаточно


универсальными, чтобы иметь возможность развертывать новые приложения,
обновлять существующие приложения и исправлять операционные системы .
Например, служба Microsoft WSUS (Windows Server Update Services) может рас­
пространять все три вида пакетов. Вся операционная система Linux представляет
собой группу из множества отдельных пакетов. Приложения Linux используют
один и тот же формат пакета. Система для распространения и установки обнов­
ленных пакетов Linux может обновлять операционную систему и приложения.
Возможность развертывания программных пакетов с помощью автоматизиро­
ванных средств является ключом к хорошо функционирующей среде.

Пример: инсталляции новой системы печати


Одна компания наняла системного администратора для того, чтобы он уста­
новил новую систему печати. Новая система была разработана, спроекти­
рована и протестирована очень быстро. Тем не менее консультант потратил
несколько недель на черную работу, устанавливая новое клиентское прог­
раммное обеспечение на каждой рабочей станции, поскольку в организации
не было автоматизированного метода для развертывания обновлений прог­
раммного обеспечения.
Позднее этот консультант был нанят для установки подобной системы в дру­
гой компании. У нее была отличная система документирования и обновления
' программного обеспечения. Массовые изменения можно было сделать легко.
Программное обеспечение клиента было быстро упаковано и распределено.
В первой компании затраты на создание новой системы печати в основном
были связаны с трудозатратами, необходимыми для развертывания прог­
раммного обеспечения. Во второй компании стоимость в основном состоя­
ла из расходов на разработку новой службы печати. Первая компания ду­
мала, что экономит деньги, не внедряя метод автоматизации развертываний
программного обеспечения. Вместо этого она тратила большие суммы денег
каждый раз, когда нужно было установить новое программное обеспечение.
У этой компании не было предусмотрительности, чтобы понять, что в бу­
дущем она будет вынуждена развернуть другое программное обеспечение.
Вторая компания сэкономила деньги в долгосрочной перспективе, вложив
немного денег авансом.

7.41. Сравнение процессов обновления и инсталляции


Автоматизация обновлений программного обеспечения похожа на автоматиза­
цию начальной инсталляции, но отличается многими важными особенностями.
• Хост находится в работоспособном состоянии. Обновления выполня­
ются на машинах, которые находятся в хорошем рабочем состоянии, в то
время как для процесса начальной загрузки требуется дополнительная ра­
бота, такая как разбиение дисков и определение сетевых параметров. Фак­
тически начальная загрузка должна работать на хосте, который находится
в отключенном состоянии, например с полностью пустым жестким диском.
Глава 7. Жизненный цикл рабочей станци и 161

• Хост уже используется. Обновления относятся к машине, которая неко­


торое время уже использовалась, поэтому клиент предполаrает, что после
обновления на ней можно будет работать. Вы не можете испортить ма­
шину! Напротив, при сбое начальной заrрузки операционной системы вы
можете стереть диск и начать работу "с нуля".
• Физический доступ не требуется. Обновления не должны требовать ва­
шеrо физическою присутствия, которое неприятно для клиентов. Кроме
тоrо, соrласование визитов является дороrостоящим занятием. Пропущен­
ные встречи, клиенты, находящиеся в отпуске, и машины в запертых каби­
нетах - все это приводит к кошмару перепланировки встреч. Физические
визиты невозможно автомати:Jировать.
• Хост может не находиться в известном состоянии. В результате автома­
тизация должна быть более осторожной, поскольку операционная система
может деrрадировать с момента ее первоначальной инсталляции. Во время
начальной заrрузки состояние машины контролируется более строrо.
• Хост находится в родной среде. Системы обновления должны иметь
возможность выполнять задание в собственной сети хоста. Они не моrут
наводнить сеть или нарушить работу друrих узлов в сети. Начальный про­
цесс заrрузки может выполняться в определенном месте, rде может быть
доступно специальное оборудование. Например, крупные орrанизации
обычно имеют специальное помещение для установки или промежуточ­
ную зону с высокой пропускной способностью, rде проходит предвари­
тельная подrотовка машин перед отправкой в офис новоrо владельца.
• У хоста могут быть активные пользователи. Некоторые обновления
нельзя устанавливать во время работы машины. Служба управления систе­
мой Microsoft решает эту проблему, устанавливая пакеты после тоrо, как
пользователь ввел свое имя пользователя и пароль для входа в систему, но
прежде, чем он получит доступ к машине. Система AutoPatch, используе­
мая в компании Bell Labs, отправляет электронную почту клиенту за два
дня до этоrо и позволяет клиенту отложить обновление на несколько дней,
создав файл с определенным именем в каталоrе / tmp.
• Хост может быть недоступен. Весьма вероятно, что хост может не всеrда
находиться в сети, коrда система обновлений хочет направить на неrо об­
новления. Эrо особенно верно для ноутбуков и дистанционных сотрудни­
ков, которые получают доступ к сети по VPN только изредка. Либо система
обновлений должна повторить попытку и надеяться поймать машину, коr­
да она будет доступна, либо машина должна опрашивать сервер для полу­
чения обновлений.
• У хоста может быть конфигурация с мультисистемной загрузкой.
В эпоху хостов с мультисистемной заrрузкой системы обновления, которые
обращаются к настольным компьютерам, должны быть осторожны, чтобы
убедиться, что они достиrли ожидаемой операционной системы. Компью­
тер с мультисистемной заrрузкой, имеющий систему Windows на одном
разделе и систему Linux на друrом, может работать в течение нескольких
месяцев в системе Linux, пропуская обновления для раздела Windows. Сис­
темы обновления для систем Linux и Windows должны быть достаточно
разумными, чтобы справляться с этой ситуацией.
162 Часть 11. Управление парком рабочих станций

7.4.2. Методы обновления


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

Б ез об нов11ений
Первая стратегия - просто никогда ничеrо не обнонлять. Во мноrих отношени­
ях это самый простой вариант, но, с друrой стороны, это самый сложный вариант.
Первоначально он требует наименьшеrо количества работы. Однако со временем
отсуrствие обновлений приведет к проблемам безопасности и друrим проблемам,
которые создают больше работы, чем было изначально сэкономлено. (Некоторые
менеджеры считают, что откладывание расходов лучше, чем экономия денег, по­
этому значительно больший расход на решение проблем бе:юпасности будет обос­
нованным. Такие ошибки в конечном итоге вызовут у них сожаление.)
Эrу стратегию можно принять, только если все новые машины были созданы
полностью исправными и акrуальными, а затем мы каким-то образом создаем
сиrуацию, в которой у нас есть только новые машины. Это кажется невозмож­
ным, особенно учитывая, насколько часто появляются новые операционные сис­
темы и обновления приложений. Однако есть две сиrуации, в которых мы дела­
ем именно это.
Как обсуждалое1, в разделе 6.2, непостоянные инфраструктуры виртуал1,ных
рабочих столов предоставляют среды рабочих станций с помощью виртуальных
машин, которые стираются и перезаrружаются "с нуля" каждый раз, когда поль­
зователь выходит из системы или перезагружается. Если пользователи выходят
из системы каждый день, их машина постоянно обновляется, а обновления появ­
ляются на их новом компьютере автоматически.
Другая ситуация, в которой эта стратегия является жи:шеспособной, - это
мир серверов. Большие службы фактически состоят из множества небольших
подслужб, называемых микрослужбами, которые работают на разных виртуаль­
ных машинах. Каждая микрослужба может быть обновлена индивидуально. Вме­
сто обновления проrраммного обеспечения на вирrуальной машине любая новая
версия проrраммноrо обеспечения приводит к созданию нового образа виртуаль­
ной машины. Старая вирrуальная машина стирается, и на ее месте запускается
образ новой вирrуальной машины. Поскольку эти изображения не обновляются,
их часто называют неизменяемыми клонами, хотя более точным описанием мо­
жет быть стандартная, или одноразовая, инфраструкrура.
Эта стратеrия уменьшает дублирование усилий. Когда новый пакет должен
быть развернут, он просто обновляется в одном месте: при инсталляции опера­
ционной системы или создании образа вирrуалыюй машины. Обновление опе­
рационной системы не требуется, поэтому работы не так много.
Другое преимущество заключается в том, что эта стратегия уменьшает потен­
циальные вариации в окружающей среде. Сравните две машины: первая машина
была установлена с акrуальным набором пакетов. Вторая машина была установ­
лена на прошлой неделе со старым набором пакетов, но сеrодня была обновлена,
чтобы включить все те же пакеты версий, что и первая машина. Теоретически
эти две машины одинаковы, но на практике это не так. Потенциально существу­
ют незначительные, но существенные различия, которые моrут вызывать ошибки
и друrие проблемы.
7
Глава . Жи зненный ци кл рабочей станци и 163

Вторая машина - это новый вариант машины, который увеличивает нагрузку


на тестирование и усложняет поддержку всех окружающих ее систем. В некото­
рых средах для каждой версии существуют десятки платформ. Использование
стандартной инфраструктуры сокращает объем тестового труда вдвое. Для орга­
низаций, которые ранее не тестировали оба варианта, это приводит к постоянно­
му тестированию качества.
Обновления, инициированные пользователем
Обновления, инициированные пользователем, означают, что обновление
машины обязан выполнять пользователь. Большинство пользователей даже не
думают обновлять свое программное обеспечение, если они не вынуждены это
делать. Иначе говоря, системы не будут обновляться, пока пользователь не по­
чувствует необходимость в новой функции. Обновления безопасности и любое
обновление, невидимое для пользователя, не будут инсталлированы.
Хотя это очень распространенная стратегия, мы не рекомендуем ее использо­
вать. Клиенты не должны нести ответственность за обновление своих машин. Это
не их работа. Это работа и компетенция системных администраторов. Может
показаться, что в этом случае вам удается уменьшить объем работы, но безопас­
ность и другие проблемы, которые приводят к печальным последствиям, в дол­
госрочной перспективе создадут для вас еще больше работы.

Автоматическое обновление с по дтверж де нием пользо вателя


Автоматизация обновлений почти всегда оптимальна. На серверах эти обнов­
ления необходимо координировать, чтобы они не вызывали прерывания обслу­
живания.
В случае реплицированных служб автоматизация может устанавливать за­
платки и перезагружать их в любое время, хотя иногда требуется специальный
процесс. Например, если служба реплицируется на двух компьютерах, ее, воз­
можно, придется отключить на одной машине, пока она обновляется, а затем
снова активизировать. Сложность того, что нужно сделать, варьируется от нуля
до очень сложных оркестровок, которые организуют переходы из одного состоя­
ния в другое и их обработку.
Если службы не реплицируются, мы можем автоматизировать специальные
вариа•rrы. Например, обновления, которые не требуют перезагрузки, моrут быть
доступны в любое время. Для других обновлений может потребоваться автома­
тизация, чтобы подождать до тех пор, пока не наступит запланированное время
обслуживания, в течение которого можно будет отключить машину.
Обновления программного обеспечения на рабочих станциях - это совсем
другое дело. Если обновление происходит, когда клиенты используют свои ком­
пьютеры, они моrут потерять результаты своей работы.
Попыткой решить эти проблемы, являются обновления, разрешенные поль­
зователями. Когда требуются обновления, пользователю предлагается разрешить
их запуск. Это повышает вероятность обновления. Тем не менее пользователи
считают эти запросы раздражающими и обычно предпочитают откладывать об­
новления навсегда.
В ответ многие системы управления обновлениями моrут откладывать обнов­
ления по мере необходимости до определенной даты, причем редкие аварийные
обновления откладываются на более короткий срок. Пользователи моrут отло­
жить обновление на несколько дней, но тоrда их надежда на то, что они моrут
164 Часть II. Управление парком рабочих станций

отложить обновление навсегда, окажется ложной. Поль:ювателям это, скорее все­


го, не понравится больше всего.
При использовании такой системы будьте снисходительны к тому, что люди
могут отложить обновление. Они лучше знают, когда обновление будет меньше
всего мешать их работе.
Итак, именно системные администраторы несут ответственность за разумное
использование таких систем. Ниже приводятся некоторые основные советы, ко­
торые мы усвоили на собственном опыте.
• Будьте великодушны, назначая срок отсрочки. Если требуется обновление,
разумно ожидать, что клиенты смогут сделать это в течение недели. Если
кто-то непрерывно работает на своем компьютере в течение недели, то
рано или поздно этому человеку все же придется сделать перерыв.
• Проверяйте все обновления. Если нет времени для проверки каждого обнов­
ления, по крайней мере отложите обновления на несколько дней с момента
его первоначального опубликования поставщиком до того момента, когда
пользователю будет предложено его инсталлировать. Большинство обнов­
лений, в которых выявлены проблемы, отзываются поставщиком в течение
пяти дней. Одним из важных аспектов тестирования является обеспечение
достаточного дискового пространства, особенно в загрузочных разделах.
• Обновления, предназначенные для чрезвычайных ситуаций, должны быть
крайне редкими, возможно, один раз в год. Кроме того, они должны со­
провождаться сообщением всем сотрудникам о том, что риск их несанкци­
онироваююго развертывания оправдывает короткий срок отсрочки.
• Сведите к минимуму вероятность обновления. Устанавливайте только абсо­
лютно минимальное программное обеспечение, требуемое на машине. Это
уменьшает вероятность того, что вам потребуются обновления. Вам будет
сложно запросить перезагрузку, чтобы обновить программное обеспече­
ние, которое вы не используете.

7.5. Вносите изменения осторожно


Теоретически, автоматизированная система обновления может нанести значи­
тельный ущерб. Вы обязаны организовать специальный процесс, чтобы обеспе­
чить управление этим риском. Процесс должен быть четко определенным и по­
вторяемым, и вам следует пытаться улучшить его после каждого повторения,
используя полученный опыт. Вы можете избежать многих бедствий, если будете
следовать этим правилам.
Автоматизированная система заплаток похожа на клиническое испытание
экспериментального противогриппо:шого препарата. Вы бы не дали непроверен­
ный препарат тысячам людей без проверки на небольших группах информиро­
ванных добро1юл1.цеn. Аналогично вы не должны выполнять автоматическое раз­
вертывание заплаток для всей компании, пока не убедитесь, что это не нанесет
серьезного ущерба.
• Создайте четко определенную версию-кандидат, которая будет распро­
страняться среди всех хостов. Назначьте ее для распространения. На­
значение начинается с этапа одобрения, чтобы получить согласие всех
Глава 7. Жизненный цикл рабочей станции 165

заинтересованных сторон. Такая практика препятствует чрезмерно востор­


женным системным администраторам распространять тривиальные и не­
нужные для бизнеса пакеты программного обеспечения по своей прихоти.
• Разверните изменения сначала в небольшой группе, затем во все больших
и больших группах, пока она не будет распределена среди всех. Каждое
повторение с другой группой называется итерацией.
• Установите критерии успеха для итерации. Убедитесь, что критерии успеш­
ности достигнуты для каждой группы до начала развертывания в следую­
щей группе. Например, если сбоев не было, то каждая последующая группа
может быть примерно на 50% больше предыдущей. Если произошел сбой,
то размер группы возвращается к одному хосту и начинает расти снова.
Разветвления неудачного процесса инсталляции заплаток отличаются от послед­
ствий отказа от загрузки операционной системы. Пользователь, вероятно, даже не
знает, что операционную систему загрузить не удалось, потому что хост, как пра­
вило, еще не был подключен к сети. Тем не менее хает, который в настоящее время
устанавливает заплатку, как правило, находится на рабочем столе сотрудника. За­
платка, которая выходит из строя и оставляет машину в непригодном для использо­
вания состоянии, гораздо более заметна и вызывает сильное разочарование.
Вы можете уменьшить риск неудачной инсталляции заплатки, используя под­
ход одна, несколько, много (one, some, technique).
• Одна. Сначала установите заплатку на одну машину. Эrа машина может
принадлежать вам, так что есть стимул все сделать правильно. Если заплат­
ка не работает, уточняйте процесс до тех пор, пока она не будет работать
на одном компьютере без сбоев.
• Несколько. Затем попробуйте установить заплатку на нескольких маши­
нах. Если возможно, придется протестировать свой автоматизированный
процесс установки заплатки на всех рабочих станциях других системных
администраторов до того, как станете делать это для пользователей - сис­
темные администраторы немного лучше подготовлены. Затем протести­
руйте его на нескольких дружелюбных клиентах за пределами группы сис­
темных администраторов.
• Много. Как только вы протестируете свою систему и обретете уверен­
ность в том, что она не уничтожит чей-то жесткий диск, медленно-мед­
ленно переходите ко все большим и большим группам клиентов, не
склонных к риску.
В очень больших средах мы можем применять это в более широком масшта­
бе. Разделите клиентов на категории по степени склонности к риску. Вносите об­
новления, начиная с наиболее склонных к риску и заканчивая наименее склонны­
ми к риску. Таким образом, большинство не склонных к риску пользователей не
должны пострадать от найденных и исправленных ранее ошибок.
Например, предположим, что у вас есть четыре группы клиентов, возможно,
в виде четырех разных отделов внутри вашей компании. У каждого есть своя сте­
пень склонности к риску. Инженерная команда предпочитает оставаться на пе­
реднем крае и принимает на себя потенциальный риск, даже желая взять на себя
ответственность за обнаружение и сообщение об ошибках перед кем-либо еще.
166 Часть 11. Управление парком рабочих станций

Огдел маркетинга меньше склонен к риску и может не обладать техническими


навыками для эффективного сообщения о проблемах. Руководители стремятся
к наименьшему риску. Кроме того, мы сами не хотим, чтобы они видели что­
то новое, пока не будут обнаружены и устранены все ошибки. Это заставляет
нас выглядеть наилучшим образом, поскольку восприятие компетенции влияет
на ее финансирование. Огдел продаж говорит, что они хотят получить новейшие
функции, но на самом деле они недооценивают тот факт, что они первыми уви­
дят большинство ошибок. Тот факт, что они сначала жалуются руководителям,
а потом сообщают об ошибках в файлах, означает, что их нельзя оставлять без
присмотра.
Таким образом, в этом примере большие изменения сначала переносятся
на вашу собственную машину, затем - на оставшуюся часть команды системных
администраторов, затем - на технический отдел, затем - на отдел маркетинга,
затем - на отдел продаж и затем - на руководителей.
Вместо того чтобы группировать сотрудников по должностям, можно группи­
ровать их по отделам или по местоположению или даже выбирать случайным
образом. Некоторые компании выбирают случайным образом 1 % первых канди­
датов, а затем переходят к группам по 10-15%, пока изменение не будет внесено
в глобальном масштабе.

Не стир айте свой университет


В мае 2014 года Университет Эмори (Emory University) случайно разослал
обновление, которое было не просто обновлением, а совершенно новым об­
разом операционной системы. В результате все компьютеры Windows, вклю­
чая ноутбуки, настольные компьютеры и серверы, начали стирать свои диски
и переустанавливать систему Windows "с нуля". Как только авария была об­
наружена, сервер SCCM был выкл ючен. К сожалению, к тому времени сервер
SCCM уже был стерт. На восстановление потребовалось несколько недель.
Это крайний, но поучительный пример. В течение многих дней автомати­
зация должна вносить изменения в небольшие группы. Хорошая автомати­
зация позволяет включать проверки безопасности и другие меры предосто­
рожности в отношении непреднамеренных результатов. И, конечно же, важ­
но помнить о том, что резервные копии, хранящиеся вне офиса, являются
необходимой страховкой от IТ-катастроф.

7.6. Утилизация
Последним этапом жизни машины является утилизация. Задачи, связанные
с утилизацией, подразделяются в основном на три категории: бухгалтерские, тех­
нические и физические.
Бухгалтерские задачи относятся к инвентаризации и подсчету налогов. Тех­
нические задачи - это работа, выполняемая системными администраторами,
включая безопасное стирание памяти. Физические задачи связаны с фактическим
удалением предмета. В разных компаниях эти задачи будут разными, но обычно
выполняются следующие операции.
Глава 7. Жизненный цикл рабочей станции 167

• Бухгалтерские задачи.
Удалить машину из инвентарной ведомости.
Списать всю рассчитанную амортизацию.
Удалить машину из любых контрактов на техническое обслуживание
оборудования.
Отменить или передать любые лицензии на программное обеспечение.
• Технические задачи, связанные с выводом машины из эксплуатации.
Переместить или вывести из эксплуатации все оставшиеся службы.
Перенести любые данные на другие хосты или на долговременные
носители, такие как лента.
Если лицензии освобождаются или передаются, выполнить техническую
работу, необходимую для этого.
Удалип, машину из систем мониторинга.
Удалить или перезаписать все пароли или сертификаты шифрования,
особенно в любых встроенных подсистемах управления (iLO, DRAC,
IPMI).
Выкл ючить машину или выполнить эквивалентную операцию над
виртуальной машиной.
Удалить машину из базы данных управления конфигурацией (CMDB -
configuгation management database), DNS и любых других баз данных или
файлов конфигурации.
• Технические задачи, связанные с защитой данных.
Физически отключить машину от сети или выполнить эквивалентную
операцию над виртуальной машиной.
Сбросить параметры всех встроенных систем управления до заводских
настроек по умолчанию.
Надежно стереть весь диск, SSD или другое хранилище.
• Физические задачи.
Отсоединить все оставшиеся кабели.
Вынуть машину из стойки.
Собрать кабели и другие детали для ремонтной мастерской.
П родать, пожертвовать или отправить машину в э кологически
сертифицированную программу утилизации электроники.

7.6.1. Бухгалтерские задачи


Бухгалтерские задачи включают в себя ликвидацию любых текущих капиталь­
ных и операционных расходов. Эrи задачи в каждой стране решаются по-разно­
му. Единственный способ узнать обо всех задачах - спросить. Совместно с соот­
ветствующим отделом разработайте контрольный список задач или процедуру,
которой необходимо следовать. Процедура может заключаться в том, что техно­
логический номер машины отправляется по электронной почте в бухгалтерию
или, во:�можно, выполняется более сложная процедура, включающая обновле­
ние ба:\ данных, проверку контрактов и т.д.
168 Часть II. Управление парком рабочих станций

Иногда списанное оборудование возвращается в магазины компании для по­


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

7.6.2. Технические задачи, связанные


с выводом из эксплуатации
Технические задачи, связанные с выводом из эксплуатации, должны выпол­
няться группой системных администраторов. Эти шаги также должны быть
перечислены в контрольном списке, чтобы они выполнялись последовательно.
Контрольный список должен учитывать порядок выполнения задач. Например,
удаление машины из систем мониторинга, вероятно, должно быть выполнено
на ранних этапах процесса, чтобы не генерировались побочные предупрежде­
ния. Операции по выводу из эксплуатации выводят машину из работы. Опера­
ции, связанные с безопасностью данных, предотвращают случайное разглашение
конфиденциальной, защищенной или личной информации.
Убедитесь, что база CMDB соответствующим образом обновляется. Если обо­
рудование возвращается в магазины компании для последующего использова­
ния, оно должно быть помечено как находящееся на складе. Если оно уничтожа­
ется, то должно быть помечено как утилизированное. В обоих случаях должны
существовать отдельные рабочие процессы со списком всех других задач, кото­
рые необходимо выполнить. В зрелых компаниях изменение статуса в базе CMDB
инициирует серию автоматических задач очистки.

7.3.3. Технические операции, связанные с защитой данных


Следует особо подчеркнуть, насколько важно правильно стереть диски и дру­
гое хранилище перед их удалением. Мы постоянно читаем сообщения о том, что
кто-то покупает подержанный сервер на еВау, только чтобы узнать, что машина
заполнена данными о кредитных карточках, медицинской документацией, личной
информацией или секретными правительственными документами. Если вы дума­
ете, что данные на этой машине больше никому не нужны, подумайте еще раз.
Стирание дисков и другого хранилища имеет решающее значение, и, к сожа­
лению, этот процесс сложнее, чем можно было бы ожидать. Наилучший спо­
соб стереть диск - использовать утилиту, которая перезаписывает каждый блок
диска несколько раз, каждый раз с другим шаблоном. Это может занять много
времени, но результат оправдывает ожидания.
Простое удаление файлов на самом деле не приводит к стиранию данных .
Этот процесс обычно изменяет таблицы распределения, чтобы указать, что уда­
ленные блоки диска доступны для повторного использования. Блоки дисков
по-прежнему содержат данные и могут быть собраны вместе, как большая мозаи­
ка. Все, кто когда-либо использовал специальную программу для восстановления
случайно удаленного файла, были рады, что она работает таким образом. Даже
форматиро11ание диска не приводит к стиранию самих данных. Для того чтобы
сэкономить время, программа форматирования диска перезаписывает таблицу
распределения, снова оставляя блоки данных неизмененными.
Казалось бы, сделав нечто столь же инвазивное, как запись нулей в каждый
блок диска, можно было бы стереть данные. Тем не менее, используя специальное
Глава 7. Жизненный цикл рабочей станции 169

оборудование, данные, перезаписанные таким образом, все еще можно восста­


новить. Поскольку нули являются очень последовательным шаблоном, все еще
существует возможность прочитать эхо данных, которые были сохранены ранее.
Поэтому системы стирания дисков обычно делают несколько проходов по диску,
каждый раз записывая случайные данные.
Одна из таких утилит Derek's Boot and Nuke (DBAN). Она загружает опера­
-

ционную мини-систему, которая запускается на виртуальном диске. Поскольку


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

7.6.4. Физические задачи


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

Проблема физического вывода из эксплуатации


В одной компании был завершен технический вывод из эксплуатации се­
тевого устройства, а физический вывод из эксплуатации был запланирован
на выходные. Во время физического вывода из эксплуатации были получены
, предупреждения для другого сетевого устройства.
Техник центра обработки данных удалил неправильное оборудование, пото­
му что, когда новое оборудование было установлено, оно было ошибочно по­
мечено именем другого устройства. Кроме того, когда эти устройства инстал­
лировались, в системе инвентаризации не было обновлено местоположение
стойки. Как следствие техник должен был полагаться на метки. К сожале­
нию, он не смог также проверить метку ресурса (которая была правильной).
Из-за избыточности, встроенной в службу, клиент не заметил реального от­
ключения. Ошибка маркировки была исправлена, и всем сотрудникам на­
помнили о важности наличия точных меток, точной системы инвентариза­
ции и процесса двойной проверки всей имеющейся информации перед фи­
зическим выводом из эксплуатации.
170 Часть 11. Управление парком рабочих станций

7.7. Резюме
В этой главе рассмотрены процессы, связанные с обслуживанием операци­
онных систем настольных компьютеров. Настольные системы, в отличие от сер­
веров, обычно развертываются в больших количествах, причем каждая система
имеет в основном одну и ту же конфигурацию.
Все компьютеры имеют жизненный цикл, начинающийся с загрузки опера­
ционной системы и заканчивается, когда машина выключается в последний раз.
В течение этого интервала программное обеспечение в системе деградирует в ре­
зультате энтропии, обновляется и перезагружается "с нуля", когда цикл начина­
ется снова. В идеальном случае все хосты определенного типа начинают работу
с одной и той же конфигурации и должны обновляться согласованно, постепен­
но выявляя проблемы, прежде чем затронуть весь парк.
Одни этапы жизненного цикла более полезны для клиентов, чем другие. Мы
стремимся увеличить время, затрачиваемое на более полезные этапы, и сокра­
тить время, затрачиваемое на менее полезные.
Все, что мы рассмотрели в этой главе, основано на трех принципах: перво­
начальная загрузка операционной системы должна быть автоматизирована, об­
новления программного обеспечения должны быть автоматизированы, а конфи­
гурация сети должна централизованно управляться с помощью такой системы,
как DHCP. Эги три принципа имеют решающее значение для руководства. Их
выполнение гарантирует, что все пройдет гладко.
Существует множество стратегий обновления операционной системы рабочей
станции. Мы можем просто не делать обновления и либо терпеть последствия,
либо стирать и перезагружать машины часто с ранее заплатанным программным
обеспечением. Мы можем думать, что пользователи будут делать обновления са­
мостоятельно, что является безответственным со стороны профессиональных си­
стемных администраторов. Мы можем автоматизировать обновления, используя
механизм, который позволяет пользователям отложить обновление, или без него.
При развертывании обновлений подход "одна, несколько, много" позволяет
защищаться от непредвиденных проблем. Одновременно мы обновляем несколь­
ко машин, ищем проблемы. В конце концов мы обновляем все большие и боль­
шие группы.
Утилизация машины сложна. Технические проблемы включают в себя копи­
рование любых данных с этой машины в безопасное место, перераспределение
лицензий и обеспечение того, чтобы от нее больше не зависела ни одна другая
машина. По соображениям безопасности память устройства должна быть стерта.
Наконец машина должна быть утилизирована экологически безопасным образом.

Упражнения
1. Назовите пять состояний жизненного цикла операционной системы ком­
пьютера.
2. Какие состояния позволяют пользователю быть продуктивным? Как мы
можем максимизировать время в этих состояниях?
З. Что такое система управления конфигурацией (СМ)?
4. Чем обновление операционной системы отличается от ее инсталляции?
Глава 7. Жизненный цикл рабочей станции 171

5. Каковы стратегии обновления программного обеспечения?


6. Какие преимущества и недостатки имеет разрешение пользователям за­
держивать или откладывать обновление программного обеспечения?
7. Какие стратегии используются в вашей организации для обновления прог­
раммного обеспечения?
8. Иногда обновление программного обеспечения выводит из строя существу­
ющее программное обеспечение или вызывает какую-то другую проблему.
Как вы можете предотвратить это в своей организации?
9. Назовите наиболее важные шаги утилизации машины.
10. Если пришло время расстаться со старой машиной, почему бы просто не
бросить ее в мусорный бак за офисом?
11. Как ваша организация управляет удалением аппаратного обеспечения?
12. В истории из раздела 7.4 описана компания, которая неоднократно тра­
тила деньги на развертывание программного обеспечения вручную вместо
того, чтобы инвестировать один раз в автоматизацию развертывания. Изу­
чите свой или чужой опыт и перечислите по крайней мере три случая, ког­
да подобные инвестиции не были сделаны. Для каждого случая назовите
причины, по которым инвестиции не были сделаны. О чем говорят ваши
ответы?
13. Приобретите подержанную машину или жесткий диск на веб-сайте еВау
или Craigslist и посмотрите, какие личные данные вы на ней найдете.
-( .§J.§J_.С.4 Q., 5l i _;
Глава
_ __ '" · A_. -(
Щ Q
@AJ
8
Д.4-.-.
.l
.

Стратегии инсталляции
операционных систем

В этой главе рассматривается процесс инсталляции операционной системы


и ее подготовки к использованию. Существует множество стратегий инсталляции
операционной системы - от полностью ручного до полностью автоматизиро­
ванного. То, насколько хорошо мы выполняем эту задачу, влияет на все остальное
в функционировании машины. Это также затрагивает все другие аспекты нашего
IТ-отдела. Это фундаментальный строительный блок нашей среды.
Если вы хорошо выполните инсталляцию операционной системы, то поль­
зователи смогут без проблем выполнять свою работу. Они потребуют от вас
меньшей помержки, что сэкономит ваше время. Если вы плохо выполните свою
работу, то производительность работы пользователя снизится. Помержка, ко­
торую он будет требовать, будет становиться все большим и большим бременем.
Мы видели множество IТ-отделов, и те из них, которые потерпели катастрофу
(вежливый синоним - "низкая производительность труда"), неизменно не име­
ли стратегии инсталляции операционной системы. Одни машины загружалис1,
и настраивались вручную, другие сохраняли настройки поставщика, а в третьих
никто не знал, как вообще была установлена операционная система.
Отсутствие автоматизации означало, что при настройке каждой новой маши­
ны требовалось несколько дней работы системного администратора, и время, за­
траченное на выполнение запросов, поступивших в службу помержки, можно
было бы не тратить, если бы машина была правильно настроена с самого начала.
Фактически большинство из этих организаций даже не имели определения того,
что представляет собой правильно сконфигурированная сеть.
Каждый высокопроизводительный IТ-отдел, который мы видели, имел про­
цесс автоматизированной инсталляции и настройки операционной системы. Та­
кой процесс экономит время, потому что выполняется быстрее. Кроме того, после
запуска автоматизированного процесса системный администратор может уйти
и сделать что-то еще. Если клиенты самостоятельно могут инициировать автома­
тизацию, она исчезает как задача для системных администраторов полностью.
IТ-отделы с низкой производительностью труда жаловались на перегру­
женность работой. Они тонули в срочных просьбах, которые мешали им брать
на себя большие проекты. Наша рекомендация всегда заключается в том, чтобы
получить контроль над процессом инсталляции операционной системы. Это ос­
вободит время для всего остального.
Такая автоматизация не возникает сама по себе. Если ее нет в вашем IТ-отде­
ле, ее создание может быть самой важной задачей, которую вы когда-либо вы­
полняли.
Глава 8. Стратегии инсталляции операционных систем 173

8.1. Согласованность важнее совер шенства


Показателем успешности любой стратегии инсталляции операционной систе­
мы является ответ на вопрос, правильно ли и согласованно ли сконфигурирова­
ны машины в итоге.
Если инсталляция операционной системы будет выполнена неправильно, то
наши клиенты пострадают. Однако страдание вызывается и несогласованностью.
Если у клиента нескол1.ко машин, то каждое неожиданное отличие - это непри­
ятный сюрприз. Каждый такой сюрприз выглядит неряшливо и компрометирует
вашу IТ-команду. Согласованность делает вашу команду более профессиональной.

Повесть о двух кофейнях


Представьте себе две кофейни, расположенные через дорогу одна от другой. :
В кофейне House of Consistently Mediocre Coffee, принадлежащей Марку, ре­
гулярно продается кофе, с которым все в порядке, но в нем нет ничего осо­
бенного. Тем не менее клиенты знают, что они могут получить кофе, кота- .
рый на вкус каждый день одинаковый.
:

В кафе Inconsistent Coffee Shop, принадлежащем Яну, каждая чашка кофе ·

может иметь как прекрасный вкус, так и ужасный . Одна чашка может во всех
отношениях превосходить кофе Марка, но, выпив кофе из следующей чаш­
ки, вы тут же выплюнете эту гадость.
Неудивительно, что клиенты предпочитают ходить в кофейню Марка. Даже
при том, что люди могут выпить кофе в кофейне Яна, они все равно идут
к Марку и избегают неприятных сюрпризов.
Рестораны давно поняли этот принцип. Забегаловка, продающая гамбур­
геры, не может продавать наилучший кофе, но она будет иметь больший
успех, если будет продавать кофе, который будет иметь одинаковый аромат
каждый ра:�. Эго может быть не самый лучший кофе, но кофейные гурманы
в любом случае не будут пить кофе в этой забегаловке. Люди, покупающие
там кофе, получат приличную чашку кофе и даже могут стать завсегдатая­
ми, если им понравится именно этот специфический аромат. Клиенты могут
добавить в кофе сахар и молоко, причем им было бы удобно, если бы они
знали, сколько точно сахара и молока будет необходимо каждый раз.

Люди предпочитают получать машины, которые настроены согласованно,


а не идеально. Совершенства достичь невозможно, особенно учитывая, что мно­
гие решения - это просто вопрос личного вкуса. Однако согласованность явля­
ется достижимой и является предпосылкой для постепенного улучшения с тече­
нием времени.
Клиентам может не понравиться определенная настройка, но если они об­
наружат, что все новые машины имеют эту настройку, они могут настроить ее
по своему вкусу. Если машина иногда устанавливается так, а в другой раз иначе,
то каждый раз эта неожиданность будет их смущать.
174 Часть 11. Управление парком рабочих станций

Несогласованность также снижает эффективность работы вашей команды.


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

Несогласованная установка Windows в компании Bell Labs


В середине 1990-х годов Том работал в отделе компании Bell Labs, который
занимался ком пьютерной поддержкой. Операционная система Microsoft
Windows тогда была новинкой, и процесс установки был ручным, неэффек­
тивным и непоследовательным. Том обнаружил, что системные администра­
торы персональных компьютеров тратили около 25% своего времени на ис­
правление проблем, возникших в результате ошибок, допущенных во время
инсталляции. Клиенты обычно не могли продуктивно работать на новых
машинах, не проведя несколько дней, а часто и целую неделю, общаясь со
службой поддержки. Эго расстраивало как системных администраторов, так
и клиентов! Эго также производило плохое первое впечатление. Знакомство
нового сотрудника с системным администратором начиналось с того, что ма­
шина сотрудника не работала.
В то время в компании работали два специалиста, которые выполняли все
инсталляции системы Windows. Когда Том поинтересовался у них, как они
' выполняют инсталляцию, те твердо заверили ero, что несмотря на то, что ин­
сталляция выполнялась вручную, процесс был одинаковым для всех машин.
Том пригласил этих двух специалистов к доске и попросил их написать спи­
сок шагов, который они выполняли в процессе инсталляции и назвать все
настройки, которые они делали. По мере обсуждения этих вопросов двумя
специалистами этот список постоянно рос. Вскоре они увидели множество
настроек, которые устанавливались по-разному в зависимости от того, кто
выполнял инсталляцию, часто основываясь на своем личном предпочте­
нии. Один установил несколько дополнительных утилит, которые "всем,
вероятно, необходимы", в то время как другой удалил некоторые утилиты
Windows, которые "люди, вероятно, не будут использовать". Один даже от­
ключал некоторые функции в пакете MS Office, которые ему не нравились,
и устанавливал некоторые значения по умолчанию в соответствии со своим
личным вкусом.
Глава 8. Стратегии инсталляции операционных систем 175

Эти два человека, которые только что несколько раз заявили, что следовали
одному и тому же процессу, теперь вступили в жаркий спор по многим во­
просам. Именно тогда их осенило, что они поставляют своим пользователям
несогласованно настроенные машины.
Они сошлись во м нении, что наилучшим способом разрешения этих кон­
фликтов будет автоматизация процесса и выражение их решений в коде.
В то время компания Microsoft официально не поддерживала автоматическую
установку Windows, но давала советы и подсказки о том, как это можно сде­
лать. Тем не менее команда автоматизировала процесс установки, заполнив ,
пробелы собственными изобретениями, преодолев препятствия и отказав­
шись от сотрудничества со сторонними компаниями (Fulmer & Levine 1998).
В течение месяца процесс инсталляции был полностью автоматизирован.
Клиенты получили улучшенный опыт взаимодействия с новыми машинами.
В качестве бонуса теперь они могли стирать и переустанавливать операци­
онную систему без обращения за помощью. Они стали более довольными
и продуктивными. Системные администраторы стали намного более счаст­
ливыми. В новом процессе были устранены все ошибки, которые могли воз­
никнуть при ручной установке. В результате системным администраторам
стало проще поддерживать пользователей и они стали тратить меньше вре­
мени на решение проблем, вызванных несоответствиями, и больше време­
ни - на более интересные проекты.

Как и при строительстве дома на фундаменте из камня, а не из песка, нам ну­


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

Закон Сегала
Человек с часами знает, который час. Человек с двумя часами никогда не
уверен.

Конечным результатом такой автоматизации является самообслуживание


процесса. Люди могут самостоятельно устанавливать или переустанавливать
176 Часть 1 1 . Управление парком рабочих станций

операционную систему, а это означает, что они могут делать это по требованию
и не тратить дополнительное время. В результате вы больше не занимаетесь не­
посредственной инсталляцией операционной системы. Вы занимаетесь поддерж­
кой автоматизации, которая обеспечивает этот процесс. Это можно сравнить
с работой на автоматической сборочной линии и обслуживанием роботов авто­
матической сборки. Последняя работа намного интереснее.
Хотя разработка такой автоматизации может потребовать времени и денег,
эти инвесrиции м ногократно окупаются. Производительность клиентов улучша­
ется из-за отсутствия проблем с конфигурацией и возможности самостоятель­
но переустанавливать службы, не дожидаясь, когда системный администратор
выполнит для них эту задачу. Она также позволяет им запрашивать функции
для дальнейшего повышения их производительности. Это улучшает производи­
тельность системного администратора, исключая работу, связанную с устране­
нием проблем, созданных несогласованностями. Эrо избавляет от необходимости
выполнять установки для пользователя, в течение которых большая часть време­
ни системного администратора тратится на ожидание. Наконец, это улучшает
моральное состояние системного администратора: делать установки вручную ­
это действительно скучно!

Гладкая повторная инсталляция ноутбука


Однажды Кристина работала на сервере, на котором вся информация о кон­
фигурации, относящаяся к машине, хранилась в базе данных (в базе CMDB,
которая обсуждается ниже). Кроме того, сервер записывал все пользователь­
ские данные на диски D : , расположенные в настольных и переносных ком­
пьютерах, помимо того что на нем самом был сетевой накопитель. Наконец
1: в нем использовались перемещаемые профили, в которых данные поль:юва­
телей и конфигурации автоматически синхронизировались по сети при вы­
ходе из системы и входе в систему.
Благодаря этому ноутбук Кристины можно было перенастроить полностью
автоматическим способом.
Однажды жесткий диск в ноутбуке Кристины сломался. Привод был заменен,
и машина была вновь подключена к сети. Она загрузилась из сети и пример­
но через четыре часа, без необходимости дальнейшего взаимодействия, была
восстановлена в п редыдущем состоянии - со всеми своими пользователь­
скими приложениями и локальными данными. Пока Кристина ждала, когда
ее собственная машина будет восстановлена, ей удалось войти на другую ма­
шину, которая автоматически установила все необходимые дополнительные
приложения и ее локальные данные, чтобы она могла продолжать продук­
тивно работать. Когда она вышла из системы, в которой временно работала,
и снова зашла на свою машину, все изменения в ее перемещаемом профиле,
включая локальные данные, были автоматически синхронизированы с вос­
становленным ноутбуком.
Именно так выглядит хорошо разработанная, зрелая система управления ра­
бочими станциями.
Глава 8. Стратегии инсталляции операционных систем 177

8.2. Стратегии инсталляции


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

8.2.1. Автоматизация
Все современные поставщики операционных систем предоставляют механизм
для автоматизации процесса инсталляции. Для системы Microsoft Windows су­
ществуют комплект инструментов Microsoft Deployment Toolkit (МОТ) и другие
варианты. Для системы RedHat Linux были созданы пакеты KickStart, для систе­
м ы DeЬian - Debconf и т.д. Для системы Solaris предназначен пакет JumpStart.
Существуют также сторонние продукты, такие как КАСЕ и Fully Automatic
Installation (FAI).
Все они имеют одни и те же основные компоненты: у них есть способ загруз­
ки по сети с сервера инсталляции. Они загружают операционную мини-систе­
му, которая запускается с виртуального диска. Поскольку эта система не зависит
от основного хранилища, она может стирать данные, разделять диски и иным об­
разом подrотавливать машину. Информация о настройке сетевых интерфейсов,
хранилищ, подсистем программного обеспечения, которые будут установлены,
и тому подобным поступает с сервера инсталляции. Как только процесс будет за­
вершен, машина будет перезагружена и вновь инсталлированная операционная
система приступит к работе.
Процесс автоматической инсталляции не требует длинного контрольного спис­
ка действий, но для нее нужна некоторая документация. Эга документация долж­
на содержать информацию о том, как запустить процесс, который часто включает
в себя специальные нажатия клавиш во время загрузки компьютера. Эга докумен­
тация также должна содержать записи обо всех операциях, выполняемых вруч­
ную, которые будут необходимы после завершения автоматической инсталляции.

Автоматизация инсталляции нескольких операционных систем


Все автоматизированные процессы инсталляции поставщиков начинают­
ся с загрузки образа, полученного по сети. Эгот процесс, который называется
РХЕ-загрузкой, зависит от DHCP. Когда какое-либо устройство включается и по­
лучает предложение запустить процесс сетевой загрузки/инсталляции, он за­
прашивает от DНСР-сервера параметры DHCP 66 (имя хоста-сервера) и 67 (имя
загрузочного файла). Именно так клиент знает, образ какой операционной си­
стемы загрузить и какой сервер предназначен для ее загрузки.
DНСР-серверы можно настроить так, чтобы предоставлять единый ответ
для всех машин в сети, или предоставлять индивидуальный ответ на осно­
ве МАС-адреса Etheгnet, или их комбинацию. Однако подход, основанный
на МАС-адресах, основан на предварительной настройке DНСР-сервера.
В зависимости от решения DHCP это может потребовать дополнительных
178 Часть 11. Управление парком рабочих станций

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


этой конфигурации на нескольких DНСР-серверах. Более масштабируе­
мое решение - это настройка параметров на сетевом уровне. Более того,
большинство DНСР-серверов будут поддерживать установку этих пара­
метров в одном месте для применения во всех сетях, настроенных на этом
DH СР-сервере.
Однако, если вы предоставляете один и тот же загрузочный образ для всех
устройств, как вы можете поддерживать сетевую инсталляцию ра:шых опе­
рационных систем? Ответ содержится в файлах конфигурации на загрузоч­
ном сервере. Чтобы :Jадать параметры у:ыа, такие как имя хоста, всем :iа­
грузочным серверам требуется файл конфигурации каждой машины . Изна­
чально предоставляя устройству ба:ювый загру:iчик операционной системы,
а также файл конфигурации, в котором указывается, какой образ загружать
в дальнейшем, вы можете использоnать одну и ту же конфигурацию DHCP
для всех операционных систем.

8.2.2. Клонирование
Для создания новых машин некоторые организации используют клонирова­
ние. Одна машина устанавливается и настраивается по желанию, и образ диска
этого компьютера где-то сохраняется. Впоследствии любая новая машина уста­
навливается путем копирования этого образа на ее жесткий диск. Оригинальная
машина называется золотым хостом (golden host), а образ называется золотым
(golden image).
Оказанию помощи в этом процессе и предоставлению специализированного
аппаратного и программного обеспечения для клонирования посвящена неболь­
шая индустрия. Первый продукт назывался Ghost. В настоящее время популяр­
ными альтернативами с открытым исходным кодом являются Clonezilla и FOG
(Fгее and Open Ghost).

Недостатки :клонирования
Автоматизация процесса инсталляции операционной системы обычно янля­
ется лучши м решением, чем клонирование, по нескольким причинам. Прежде
всего, если аппаратное обеспечение новой машины существенно отличается
от старой, вы должны сделать отдельный мастер-образ. Чере:i короткий проме­
жуток времени вы получите много мастер-образов. Эrо о:шачает, что вы попа­
ли в ситуацию, когда необходимо внести какие-либо изменения в каждый ма­
стер-образ.
Кроме того, клонирование скрывает историю. Образ клона за долгие годы
может накопить незначительные изменения. Записи о том, почему и как прои­
зошло каждое изменение, отсутствуют. В результате получается образ, который
нельзя восстановить из исходных материалов. Если сделано неудачное измене­
ние, единственный способ восстановить работу - вернуться к последнему извест­
ному хорошему образу. Конкретные изменения, сделанные после этой ревизии,
неизвестны или плохо определены. Вероятно, вы забудете одно из этих измене­
ний или сделаете их по-другому, создав непонятные нарианты, затрудняющие
Глава 8. Стратегии инсталляции операционных систем 179

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

Автоматиче ское создание образов


Многие из этих недостатков можно смягчить или устранить, автоматизировав
создание золотого образа таким образом, чтобы его можно было легко воспро­
извести. Packer (https : / /www . packe r . i o / i nt ro) и Vagrant (ht t p s : / /www . va­
grantup . com/) это две системы, позволяющие автоматизировать создание об­
-

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


для создания образа. Этот процесс может быть повторен в любое время. Если
в образ необходимо внести изменения, они добавляются в файл конфигурации,
а новый образ создается "с нуля" .
В файл конфигурации включаются директивы, которые упрощают опреде­
ление процесса. Например, можно использовать следующий процесс: начать
с версии 7.1 установочного образа производителя; добавить дополнительные
файлы (со списком местоположений источников и адресатов; установить ключи
продукта, инструкции по изменению конкретных файлов конфигурации, специ­
фикации для настройки сетевых интерфейсов в зависимости от их количества
и скорости и т.д. Этот конфигурационный файл может храниться в репозитории
исходного кода, что позволяет легко отслеживать изменения.
Самое главное заключается в том, что, когда поступает новая версия опера­
ционной системы, создание нового образа может быть таким же простым, как
обновление исходного образа поставщика, указанного в файле конфигурации.
Если новая версия операционной системы существенно отличается от старой, на­
пример при переходе от Windows 2012 R2 к Windows 10, то может потребоваться
создание нового файла конфигурации "с нуля". Однако у вас есть предыдущий
файл конфигурации, в котором содержится информация о том, какие типы из­
менений необходимо реплицировать.

Гибридное клонирование и автоматизация


Некоторые организации используют гибрид клонирования и автоматизации.
Для инсталляции м инимальной операционной системы используется золотой
образ, а оставшаяся конфигурация обеспечивается с помощью автоматизирован­
ного процесса, например системы распространения програм много обеспечения,
которая периодически запускается на всех машинах для распространения при­
ложений и заплаток.
Благодаря такому подходу золотой образ меняется редко и поэтому его легче
поддерживать.
180 Часть 11. Управление парком рабочих станций

. Испо11ьзование клонов для ускорения инста1111яции


У одной компании был полностью автоматизированный процесс инсталля­
.
. ции, который был очень сложным и всеобъемлющим. К сожалению, он так-
..
же был медленным, и на его выполнение уходил почти час. Пол 1.зователи
виртуальной среды требовали более быстрой инсталляции, чтобы им было
, легче создавап, временные машины.
•· Системный администратор перенес все общие задачи инсталляции на ран­
нюю стадию автоматизации . Задачи, специфичные для машины, были пе­
ренесены в конец. Для создания снимка машины после завершения общих
..
задач испол1.зовался интерфейс прикладного программирования хранили-
ща менеджера 1шртуализации. Программное обеспечение для инсталляции
.
было изменено так, чтобы использовать этот снимок в качестве золотого об-
раза, а для завершения остающихся задач, учитывающих специфику машин,
использовать автоматизацию. Новое время инсталляции составляло менее
пяти минут.
' Предыдущий, более медленный, процесс инсталляции продолжал исполь­
•: зоваться для физических машин и при подготовке новых золотых образов
, для кластера виртуализации.

8.2.3. Ручная инсталляция


Сам ы й простой и наименее предпочтительный способ инсталляции и на­
стройки операционной системы - ручной. Вы вста вляете инсталляционный
DVD-диск, загружаетесь, отвечаете на несколько вопросов, и после этого процесс
стирает жесткий диск компьютера и инсталлирует операционную систему. Как
правило, вопросы касаются конфигурации сетевого интерфейса, разбиения жест­
кого диска, конфигурации сетевого каталога и дополнительных программных
подсистем. Фактическая инсталляция может занять несколько минут или часов.
Как только этот процесс будет завершен, система будет находиться в чистом
состоянии модели по Эварду, как описано в разделе 7.1, и должна быть скон­
фигурирована до того, как будет фактически использоваться. Ручное конфигури­
рование может включать в себя инсталляцию приложений, включение или от­
ключение различных функций и параметров и т.д. В зависимости от требований
организации этот процесс может состоять из десятков или сотни шагов.
Как говорилось ранее, ручная инсталляция приводит к созданию несовмести­
мых между собой машин. Тем не менее есть случаи, когда ручная инсталляция
является единственным возможным выбором. Одна из таких ситуаций возникает,
когда операционная система является новой, а средства автоматизации инстал­
ляции еще не были созданы. В идеале в этом случае вы вручную устанавливаете
операционную систему для получения опыта, необходимого для автоматизации
этого процесса. Другая ситуация возникает, если сеть настолько мала, что новые
машины устанавливаются слишком редко, чтобы оправдать создание такой авто­
матизации. Слишком часто, однако, в таких сетях есть один системный админис­
тратор, который перегружен работой, которую можно было бы облегчить с по­
мощью такой автоматизации.
Глава 8. Стратегии инсталляции операционных систем 181

Наконец еще одна ситуация возникает, когда машина принадлежит дистан­


ционному сотруднику с ограниченной пропускной способностью. Обычно авто­
матизированные системы инсталляции операционной системы не работают че­
рез сети удаленного доступа из-за необходимости иметь большую пропускную
способность для передачи всей операционной системы на машину, или потому,
что для процесса инициирования требуется специально настроенная сеть. К сча­
стью, были разработаны решения этих проблем.
Некоторые системы могут со:'\давать пользовательские инсталляционные но­
сители, которые записываются на DVD-диск или USВ-накопитель. Их можно
отправить дистанционному работнику или сделать доступными для загрузки.
Процесс инсталляции носит полностью автономный характер, по крайней мере
на начальных этапах, после чего система может загрузить остальные части.
Другие системы предоставляют общий загрузочный носитель, который ини­
циирует процесс инсталляции, после чего пользователь вставляет инсталляцион­
ный DVD-диск поставщика. Поскольк