В то время как гибкость, безусловно, важна, в некоторых областях имеет смысл располагать инструментами, которые не обговариваются в рамках команды или организации. Например, если имеются инструменты, которые позволяют поддерживать SOX, PCI либо другой уровень соответствия, имеет смысл настаивать на том, чтобы все, кто работает в этой области, использовали данные инструменты. Вероятно, есть смысл свести набор необходимых инструментов к минимуму, хотя, безусловно, есть области, в которых использование таких инструментов оправданно.
Мы решили принять технологию X (или отказаться от нее), но люди не хотят ее использовать (или отказаться от нее)
Степень открытости людей, использующих новый инструмент в работе, во многом зависит от процесса, в котором был выбран этот конкретный инструмент. Если у вас сложилась ситуация, когда было принято решение «сверху вниз», возможно, менеджером, который имеет меньший опыт работы с данным инструментом или рабочим потоком, чем обычные сотрудники, это может послужить весьма веской причиной для отказа от применения инструмента. Чтобы избежать появления подобных ситуаций, исследуйте проблемы, которые вы пытаетесь решить. Также поработайте с людьми, которые будут часто использовать этот инструмент, как описано ранее. Как отмечено выше, возможно, придется пройти длинный путь, прежде чем подобные ситуации перестанут возникать.
Обратите внимание на то, как изменяется стиль общения и как откатить эти изменения обратно. Представьте, что компьютеры сотрудников управляются централизованно, из точки, в которой изменения программного обеспечения могут выполняться ИТ-персоналом удаленно. В одно прекрасное утро люди приходят на работу и видят, что был установлен новый компонент программного обеспечения. Причем это было сделано без объяснения функций этого компонента и, что более важно, без сообщения о цели этого изменения. В подобной ситуации сотрудники, скорее всего, будут сопротивляться изменениям, даже если они полезны.
Проинформируйте людей заранее о предстоящих изменениях набора инструментов, которые повлияют на них. Дайте им возможность поучаствовать в процессе изменений. Вы можете обнаружить, что люди, которые, по вашему мнению, даже не знают, как работать с инструментом, имеют свое, и весьма неплохое, мнение об этом инструменте. Как только будут приняты решения, сообщайте об этом заранее, задолго до внедрения изменений. Дайте людям больше времени для перехода к использованию нового инструмента. Либо дайте им возможность привыкнуть обходиться без инструмента, от которого вы собираетесь отказаться. Объясните, что именно изменилось, как был сделан выбор. Дайте людям знать, как они смогут связаться с вами или сообщить о возникших проблемах.
Описанная в разделе методика относится как к добавлению новых инструментов, так и к отказу от существующих. Эти изменения приобретут необратимый характер и станут полезными при наличии достаточного уровня общения и эмпатии в организации.
Часть V. Масштабирование
Глава 14. Масштабирование: критические точки
Эта глава посвящена способам выявления и преодоления трудностей, возникающих на основных этапах жизненного цикла организаций. На первый взгляд может показаться, что проще все свести к идее «корпоративных devops-практик», как обычно поступают многие, когда идет речь о методологиях devops, которые не используются в стартапах и небольших компаниях. Но это было бы слишком просто, хотя подобные devops-практики и включают некоторые специфичные для корпораций моменты, которые будут рассмотрены в настоящей главе. Гораздо лучше было бы описать процесс изменения компании с течением времени, будь то рост и развитие стартапа или разделение крупной организации на две отдельные компании. С помощью масштабирования описываются эволюция, рост и продвижение организации как единого объекта на всех этапах ее жизненного цикла.
Довольно сложно предугадать тот момент, когда в команде, отделе или организации необходимо внедрять те или иные изменения. Поскольку эти изменения порой неочевидны, весьма полезными будут некоторые советы по их внедрению.
Если мы рассматриваем прогресс в качестве составной части разнородного ландшафта, который либо способствует, либо мешает будущим начинаниям, это поможет нам планировать, выполнять и корректировать текущее состояние с учетом предварительно поставленных целей. Эти цели могут достигаться как постепенными, но управляемыми действиями, так и динамическими скачками. Опыт обычно подсказывает, когда и как следует менять направление прогресса, а также то, какие стратегии нужно применять в тех или иных средах.
В этой главе освещаются причины возникновения проблем, возникающих в процессе масштабирования организаций. Кроме того, вниманию читателя предлагается детальное рассмотрение взаимодействия между тремя рассмотренными ранее столпами эффективных devops-практик и различными разновидностями проблем, возникающих в процессе масштабирования. В продолжение темы предыдущих глав будут рассмотрены некоторые неправильные представления и общие вопросы, возникающие в процессе устранения проблем.
Не существует «корпоративных devops-практик», предусматривающих использование уникальных инструментов и методик, которые применялись бы исключительно в компаниях, в которых работает большое количество сотрудников. Также не существует единого определения успеха, позволяющего получить однозначный результат, к которому стремятся все компании и организации. Чтобы успешно внедрять изменения, нужно превратить организацию в удобный для применения и сбалансированный инструмент, обладающий необходимой степенью гибкости.
Как в крупных компаниях, так и в небольших организациях необходимым условием для выработки силы, баланса и оперативности является devops-пакт. Культура сотрудничества и близости способствует укреплению «слабых связей» и более оперативному распространению информации внутри компании. Крупные организации отличаются друг от друга способами применения принципов, а не самими принципами.
Многие полагают, что devops-практики могут применяться только в новых проектах, выполняемых в небольших стартапах, и непригодны в крупных компаниях или наследственных системах, которым присущи технические и культурные долги. Тем не менее в отчете 2015 State of DevOps Report (отчет о состоянии devops за 2015 год), подготовленном компанией Puppet Labs, утверждается, что это далеко не так (https://puppet.com/resources/white-paper/2015-state-devops-report).
Высокая производительность достигается за счет контролируемости и развертываемости.
Исследователи, подготовившие этот отчет, обнаружили, что культурные принципы devops могут применяться в любых организациях, независимо от их размеров. Кроме того, такие технические принципы, как процесс непрерывной доставки и улучшенного развертывания, применимы для любого хорошо разработанного и спроектированного проекта по разработке ПО, включая унаследованный программный код, который выполняется на мэйнфреймах. Абсолютно новый проект, основанный на использовании микросервисов, не может быть успешным по причине своей новизны и тех же микросервисов. Он должен быть тщательно спроектированным, проверяемым и легко развертываемым. Эти принципы применяются по отношению ко всем программным проектам, как старым, так и новым.
Стратегическое расширение или сокращение организаций с помощью devops
Успешные организации должны знать способы масштабирования в тех случаях, когда возникает необходимость расширения или сокращения. В зависимости от ситуации и исполнителей изменяются трактовки масштабирования. Таким образом, масштабирование является еще одним примером народной модели, поэтому для эффективного обсуждения этого процесса в организации следует уточнить вид масштабирования. Например, масштабирование может подразумевать следующее:
• расширение клиентской базы;
• увеличение прибыли;
• расширение проекта или команды с целью достижения соответствия определенным требованиям;
• поддержка или улучшение соотношения количества сотрудников и систем либо денежных затрат;
• более быстрый рост по сравнению с конкурентами.
Дополнительные сложности возникают из-за модификаторов, которые придают дополнительный вес терминам. Пример использования модификатора – словосочетание «крупномасштабные» системы. Насколько «крупными» считаются системы, если с помощью управляемых служб один инженер может быстро развернуть и свернуть сотни систем буквально за считанные минуты, а не за месяцы, как это было ранее? Если рассматривать эту проблему через призму быстро развивающейся доступности систем, то возникает вопрос о том, существует ли набор принципов, методов и технологий, применимых в определенном поднаборе организаций?
Ответ на этот вопрос отрицательный. В дополнение к практикам, рассмотренным в части IV, в 2015 году компания Etsy насчитывала около 800 сотрудников, 1,5 млн активных продавцов и 22,6 млн активных продавцов с годовым объемом продаж 1,93 млрд долларов. Как показывает другой пример, компания Target в 2015 году насчитывала около 347 тыс. сотрудников и имела 72 млрд долларов годового дохода. Несмотря на различия в размерах, обе компании адаптировали принципы и методы, основанные на текущих культурах. В результате были выбраны стратегии, которые являются оптимальными в современных условиях.
Невозможно выработать единый механизм, который позволил бы решить все проблемы, особенно связанные с устранением человеческого фактора из систем. В реальном мире архитекторы разрабатывают проекты на основе своих знаний, опыта, интуиции и механического процесса. Проект здания зависит от ряда факторов, среди которых технические требования, особенности прилегающей территории, историческая обусловленность, а также влияние окружающей среды.