озможности изучить что-то новенькое, а другие предпочтут уже знакомые им технологии и с неохотой отнесутся к необходимости тратить большое количество времени и энергии на изучение новых языков и методик.
• Изменение образа мышления. Если члены вашей команды долгое время управляют инфраструктурой вручную, они уже привыкли вносить изменения напрямую: например, путем выполнения команд на сервере по SSH. Для перехода на IaC нужен сдвиг в образе мышления: все изменения вносятся опосредованно — сначала вы редактируете и сохраняете свой код, а затем ваши правки применяются каким-то автоматическим процессом. Такой уровень абстракции понравится не всем. При выполнении простых задач он будет казаться более медленным, чем прямой подход, особенно когда вы все еще изучаете новое средство IaC и не умеете использовать его эффективно.
• Издержки упущенной выгоды. Инвестируя время и ресурсы в один проект, вы косвенно обделяете другие проекты. Какие из них придется приостановить, чтобы мигрировать на IaC, и насколько они важны?
Некоторых членов вашей команды этот список только подзадорит. Но многие другие, включая ваше начальство, тяжело вздохнут. Изучение новых навыков, освоение новых инструментов и принятие нового образа мышления может пойти на пользу или провалиться, но одно известно наверняка: за все это придется заплатить. Переход на IaC — существенное вложение, которое, как и любое другое, имеет потенциальные плюсы и минусы.
Ваше начальство будет особенно обеспокоено издержками упущенной выгоды. Одна из ключевых обязанностей любого руководителя — следить за тем, чтобы команда работала над самыми приоритетными проектами. Когда вы приходите и начинаете восторженно рассказывать о Terraform, ваш начальник может думать про себя: «О нет, это похоже на огромное начинание, сколько времени это займет?» Это не означает, что ему непонятны возможности Terraform. Просто время, потраченное на эту технологию, могло бы уйти на развертывание нового приложения, о котором уже несколько месяцев просит команда, занимающаяся поиском, или на подготовку к аудиту PCI (Payment Card Industry), или на расследование перебоев в работе, случившихся на прошлой неделе. Поэтому, если вы хотите убедить свое начальство в том, что ваша команда должна внедрить у себя IaC, продемонстрировать ценность этой технологии недостаточно. Вы должны показать, что польза, которую она принесет вашей команде, перевешивает выгоду от любых других проектов, которыми вы могли бы заниматься в это время.
Один из наименее эффективных способов, как этого можно добиться, заключается в перечислении возможностей вашего любимого средства IaC. Например, инструмент Terraform декларативный, поддерживает разные облака и имеет открытый исходный код. Это одна из многих ситуаций, когда разработчикам есть чему поучиться у коллег из отдела продаж. Большинство продавцов знают, что для продажи продуктов не следует сосредотачиваться на их технических возможностях. Основное внимание лучше уделять преимуществам: то есть вы должны говорить не о том, что может делать продукт («продукт X может делать Y»), а о том, что может делать ваш клиент с помощью этого продукта («вы можете делать Y, используя продукт X!»). Иными словами, покажите клиенту, какие удивительные возможности предоставляет ваш продукт.
Например, вместо того чтобы рассказывать своему начальнику о декларативности Terraform, убедите его, что ваша команда сможет быстрее справляться с проектами. Вместо разговоров о поддержке разных облаков расскажите о душевном спокойствии, которое обретет ваш начальник, зная о том, что потенциальный переход с одного облака на другое не потребует замены всего инструментария. И вместо объяснения преимуществ открытого кода помогите своему начальнику осознать, насколько проще будет искать новых разработчиков среди большого и активного сообщества Open Source.
Иллюстрация преимуществ послужит отличным началом. Однако существует еще более эффективная стратегия, известная самым лучшим продавцам: фокусирование на проблемах. Если понаблюдать за тем, как умелый продавец общается с клиентом, можно заметить, что большую часть разговора он выступает в роли слушателя, пытаясь понять одну конкретную вещь: какую ключевую проблему пытается решить клиент? Какая у него основная «болевая точка»? Лучшие продавцы пытаются решить проблемы своих клиентов, а не продать им какие-то возможности или преимущества. Если так получается, что предложенное решение включает в себя один из продуктов продавца, это, конечно, плюс, но основное внимание уделяется решению проблем, а не продаже как таковой.
Поговорите со своим начальником и попытайтесь понять наиболее важные проблемы, над которыми он работает в этом квартале или году. Может оказаться, что их нельзя решить с помощью IaC. И это нормально! Возможно, из уст автора книги о Terraform это прозвучит как ересь, но технологии IaC нужны не всем командам. Их внедрение требует относительно больших затрат, которые в долгосрочной перспективе могут окупиться, а могут и нет. Например, если вы работаете в крошечном стартапе с одним системным администратором, или пишете прототип, который может быть выброшен через несколько месяцев, или просто занимаетесь сторонним проектом в свое удовольствие, управление инфраструктурой вручную часто является правильным выбором. Иногда, даже если технологии IaC отлично подходят для вашей команды, переход на них может иметь не самый высокий приоритет, поэтому, учитывая ограниченные ресурсы, лучше сосредоточиться на других проектах.
Если вы все же обнаружите, что одну из ключевых проблем, с которыми борется ваш начальник, можно решить с помощью IaC, покажите ему, как это может выглядеть. Представьте, к примеру, что одна из таких проблем — увеличение времени доступности. В последние месяцы у вас произошло множество перебоев в работе с многочасовыми простоями; ваши клиенты недовольны, а генеральный директор не дает спуску вашему начальнику, ежедневно наведываясь, чтобы проверить состояние дел. Вы начали исследовать проблему и обнаружили, что половина перебоев вызвана человеческим фактором во время развертывания: предположим, кто-то случайно пропустил важный этап процесса выкатывания, кто-то неправильно сконфигурировал сервер или инфраструктура финального тестирования не совпадала с тем, что у вас было в промышленной среде.
Теперь вместо рассказов о возможностях и преимуществах Terraform начните свой разговор с начальником со следующего: «У меня есть идея относительно того, как уменьшить число перебоев вдвое». Это гарантированно привлечет его внимание. Используйте данную возможность, чтобы обрисовать будущее, в котором ваш процесс развертывания полностью автоматизирован, надежен и воспроизводим, благодаря чему удастся исключить человеческий фактор, который был причиной половины предыдущих перебоев. Более того, с автоматизацией развертывания можно внедрить автоматические тесты, что сократит время простоя еще сильнее и позволит всей компании выкатывать обновления в два раза чаще. Пусть ваш начальник осознает, что именно он будет рассказывать об этих новостях генеральному директору. И в конце упомяните о том, что согласно вашим исследованиям эту красочную картину можно воплотить в жизнь с помощью Terraform.
Конечно, нет никакой гарантии, что начальник согласится, но этот подход увеличит ваши шансы. А чтобы повысить их еще сильнее, переход нужно осуществлять поэтапно.
Сделайте переход постепенным
Один из важнейших уроков, которые я усвоил за время своей профессиональной деятельности: большинство крупных программных проектов проваливаются. Если взять мелкие ИТ-проекты (с бюджетом меньше миллиона долларов), то три четверти из них завершаются успешно, тогда как только один из десяти крупных проектов (дороже 10 миллионов долларов) удается завершить вовремя и без выхода за рамки бюджета, а каждый третий и вовсе закрывается на полпути58.
Поэтому я всегда начинаю волноваться, когда вижу, как компания пытается внедрить IaC одним махом в огромную инфраструктуру и с участием каждой команды. Причем это часто происходит в рамках какой-то более масштабной инициативы. Не могу не покачать головой, когда генеральный и технический директора большой компании приказывают в шестимесячный срок перевести все в облако, закрыть старые вычислительные центры и сделать так, чтобы все «занимались DevOps» (что бы это ни означало). Я не преувеличиваю, когда говорю, что подобные ситуации встречались мне не один десяток раз, и всегда эти инициативы проваливались. Два-три года спустя каждая из этих компаний по-прежнему в процессе миграции, старые вычислительные центры все еще работают, и никто точно не может сказать, занимается ли он DevOps.
Если вы хотите достичь успеха с внедрением IaC или любым другим процессом миграции, у вас есть только один вариант — инкрементальные изменения. Для этого недостаточно разбить задачу на небольшие последовательные шаги. Важно, чтобы каждый шаг приносил какую-то пользу, даже если он внезапно окажется последним.
Чтобы понять, почему это так важно, рассмотрим противоположный подход — ложный инкрементализм59. Представьте, что вы разбили масштабный процесс миграции на несколько мелких этапов и только по окончании последнего из них получите какую-то реальную пользу. Например, на первом этапе вы переписали клиентскую часть, но ее нельзя запускать, так как она зависит от новой серверной части. Затем вы переписываете серверный код, но его тоже нельзя использовать, пока данные не будут перенесены в новое хранилище. И только после окончания последнего этапа вы сможете все запустить и убедиться, что вся эта работа была проделана не зря. Ждать завершения проекта для получения какой-либо выгоды очень рискованно. Если проект отменят, приостановят или существенно изменят на полпути, вложенные вами время и усилия могут не окупиться.
Именно это и происходит со многими масштабными процессами миграции. Проект изначально большой и, как это часто случается в мире программного обеспечения, требует куда больше времени, чем ожидалось. Пока он реализуется, могут поменяться рыночные условия или закончиться терпение у заинтересованных сторон (например, генеральный директор был не против потратить три месяца на ликвидацию технического долга, но после 12 месяцев уже пора выпускать новые продукты), и в итоге проект закрывается, так и не завершившись. Ложный инкрементализм дает наихудший из возможных результатов: вы заплатили огромную цену, а взамен не получили абсолютно ничего.