Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

Глава 13. Инструменты: заблуждения и устранение неполадок
275
Можно купить devops «в упаковке» или devops
в качестве услуги
Растущее влияние и популярность devops привели к быстрому росту поставщиков, которые включили связанные с devops словечки в свою маркетинговую политику, чтобы попытаться «быть в тренде». Порой бывает нелегко провести границу между маркетинговой шумихой и реальностью, особенно если эти идеи для вас новые либо вас просто «забросали» огромным количеством предложений по продаже devops.
Чтобы сформировать более сбалансированный взгляд, следует учитывать четыре столпа devops. Помимо инструментов нужно учитывать сотрудничество, бли- зость и масштабирование. Возможно, неплохо иметь набор разных инструментов
«в упаковке» либо в качестве услуги, но, как уже было сказано ранее, просто иметь нужный набор инструментов devops недостаточно. Чтобы преуспеть во внедрении devops, нужно научиться использовать инструменты эффективно.
Практики devops — это намного больше, чем просто инструменты. Ответьте на следующие вопросы. Каким образом вы продаете сотрудничество в качестве услу- ги? Что вы можете сказать об инструменте, помогающем устранить определенные проблемы, связанные с сотрудничеством или общением, и о фактической деятель- ности людей, работающих вместе? Как насчет того, чтобы члены разных команд сели рядом и обсудили разные цели, приоритеты и проблемы? Все это вы не сможете купить «в упаковке» или в качестве услуги. В конце концов сотрудники вашей организации должны выработать общее понимание, которое описывается как devops-компакт. В соответствии с этим пониманием должны быть выполнены внутренние изменения в вашей организации.
Существует множество великих инструментов и услуг. Многие компании пред- лагают решения, которые способствуют решению реальных проблем. Когда вы слышите слово «devops» в маркетинговых кампаниях, представляйте четыре столпа devops наравне с взаимодействиями и пересечениями. При этом спросите себя, реальны ли обещания, щедро раздаваемые маркетологами. Просто замените слово «devops» в рекламном слогане фразой «людям хорошо работается вместе» и подумайте, имеет ли смысл полученное предложение. Если оно звучит глупо или смешно, вряд ли следует доверять подобному рекламному слогану.
В конечном счете вам самостоятельно придется делать всю тяжелую работу, вместе со своими людьми и командами выяснять, что именно работает или не работает в вашей организации. Устойчивые изменения в культуре невозможно купить, их придется создавать самостоятельно.
Поиск и устранение проблем,
связанных с инструментами
Имейте в виду, что в процессе поиска и устранения проблем, связанных с исполь- зованием технологий, не следует относиться к инструментам как к игрушкам.

276
Часть IV. Инструменты
Нужно выбирать инструменты, которые будут решать проблемы. Нет причин менять что-либо просто так, без оснований.
Мы пытаемся найти лучшие практики для технологии X
Иногда удобно искать наилучшую практику для конкретной поставленной задачи, но подобное мышление может заложить основу для проблем в будущем. В про- цессе выбора «наилучшего» решения, которое оказывается неработоспособным, возникает когнитивный диссонанс, за которым зачастую следует чувство вины.
Прежде чем погрузиться в решение какой-либо проблемы, попробуйте применить несколько ключевых стратегий.

Идентифицируйте состояние проблемы в настоящее время.

Определите нужные вещи и полезные штучки.

Идентифицируйте сотрудников и команды, которые обладают критически важной информацией, и работайте с ними над дальнейшим уточнением проблемы. В данном случае цель заключается не в том, чтобы выяснить все возможности, а в том, чтобы определить, какие компоненты требуют изменений, а какие критически важны для решения текущих задач. Бла- годаря наличию разнородной команды, включающей людей с аналитиче- ским, нешаблонным или творческим складом ума, создается потенциал для решения проблем, которые могут возникнуть в будущем.
В процессе выполнения вышеописанного процесса идентификации вы откроете для себя паттерны конкретных проблем. Как только в вашем распоряжении по- явится соответствующий паттерн, сравните его с имеющимися вариантами. Яв- ляются ли варианты нежизнеспособными? Что будет, если выбрать один из этих вариантов? Что будет, если создать что-то совешенно новое?
Примите решение о документировании процесса принятия решений таким обра- зом, чтобы был понятен осознанный характер решения. Идентифицируйте фак- торы гибкости, которые рассматриваются в качестве потенциальных улучшений в будущем. Какие фундаментальные проблемы связаны с этими решениями? Так- же следует иметь в виду, что планирование является составной частью процесса использования инструментов или технологий, особенно когда предусматривается использование автоматизации. При всей пользе автоматизации без надлежащего планирования можно автоматизировать дефектный процесс. В результате ситуа- ция станет еще хуже, чем раньше.
Убедитесь в том, что люди не только принимают решения и работают, но и до- кументируют условия «что, если?». В результате ваша команда сможет иден- тифицировать используемое в данный момент решение, получить согласие руководства и быть готовой к изменениям по мере развития и роста технологий.
Также нужно быть готовыми к сбоям в системе и к появлению непредвиденных проблем.

Глава 13. Инструменты: заблуждения и устранение неполадок
277
Мы не можем заставить людей согласиться
на использование конкретного инструмента
В небольших организациях можно попытаться получить согласие у каждого чело- века на использование (или отказ от применения) какого-либо инструмента. Более того, в маленьких стартапах эта методика окажется успешной. Но по мере «разбу- хания» команды и организации это будет все труднее и труднее. После достижения определенного размера и уровня сложности вряд ли целесо образно налаживание обратной связи с каждым человеком, использующим тот или иной инструмент, не говоря уже о получении согласия на использование данного инструмента.
Как только вы поняли, что достичь единодушного согласия на использование ин- струмента не представляется возможным, можете переходить к поиску решения, имеющего смысл для большинства вариантов использования. Вполне возможно, что вы захотите идентифицировать людей, использующих инструменты ежеднев- но. Для таких людей есть смысл в оптимизации потребностей и вариантов исполь- зования. Не имеет смысла уделять особое внимание людям, которые используют инструмент эпизодически. Возможно, стоит сформировать группу из нескольких тестеров, которая вероятно представляет большинство общих вариантов исполь- зования инструмента. Можно также позволить людям стать бета-тестерами, чтобы помочь оценить возможные решения.
Многие инженеры и техники не хотят каких-либо перемен. Как правило, они выступают против внедрения новых инструментов не потому, что не испытывают каких-либо проблем, а потому, что просто к ним привыкли. Разработайте струк- турированный способ осуществления обратной связи, позволяющий высказать мнение об используемых инструментах. Благодаря такой связи вы сможете уста- новить, как часто пользователи сталкиваются с проблемами, а также идентифици- ровать сами проблемы. И не забывайте о том, что те, кто громче всех жалуется на проблемы, не обязательно выражают мнение большинства.
В то время как гибкость, безусловно, важна, в некоторых областях имеет смысл рас- полагать инструментами, которые не обговариваются в рамках команды или орга- низации. Например, если имеются инструменты, которые позволяют поддерживать
SOX, PCI либо другой уровень соответствия, имеет смысл настаивать на том, чтобы все, кто работает в этой области, использовали данные инструменты. Вероятно, есть смысл свести набор необходимых инструментов к минимуму, хотя, безусловно, есть области, в которых использование таких инструментов оправданно.
Мы решили принять технологию X (или отказаться от нее),
но люди не хотят ее использовать (или отказаться от нее)
Степень открытости людей, использующих новый инструмент в работе, во многом зависит от процесса, в котором был выбран этот конкретный инструмент. Если у вас сложилась ситуация, когда было принято решение «сверху вниз», возможно,

278
Часть IV. Инструменты менеджером, который имеет меньший опыт работы с данным инструментом или рабочим потоком, чем обычные сотрудники, это может послужить весьма веской причиной для отказа от применения инструмента. Чтобы избежать появления подобных ситуаций, исследуйте проблемы, которые вы пытаетесь решить. Также поработайте с людьми, которые будут часто использовать этот инструмент, как описано ранее. Как отмечено выше, возможно, придется пройти длинный путь, прежде чем подобные ситуации перестанут возникать.
Обратите внимание на то, как изменяется стиль общения и как откатить эти из- менения обратно. Представьте, что компьютеры сотрудников управляются цент- рализованно, из точки, в которой изменения программного обеспечения могут выполняться ИТ-персоналом удаленно. В одно прекрасное утро люди приходят на работу и видят, что был установлен новый компонент программного обеспечения.
Причем это было сделано без объяснения функций этого компонента и, что более важно, без сообщения о цели этого изменения. В подобной ситуации сотрудники, скорее всего, будут сопротивляться изменениям, даже если они полезны.
Проинформируйте людей заранее о предстоящих изменениях набора инструмен- тов, которые повлияют на них. Дайте им возможность поучаствовать в процессе изменений. Вы можете обнаружить, что люди, которые, по вашему мнению, даже не знают, как работать с инструментом, имеют свое, и весьма неплохое, мнение об этом инструменте. Как только будут приняты решения, сообщайте об этом зара- нее, задолго до внедрения изменений. Дайте людям больше времени для перехода к использованию нового инструмента. Либо дайте им возможность привыкнуть обходиться без инструмента, от которого вы собираетесь отказаться. Объясните, что именно изменилось, как был сделан выбор. Дайте людям знать, как они смогут связаться с вами или сообщить о возникших проблемах.
Описанная в разделе методика относится как к добавлению новых инструментов, так и к отказу от существующих. Эти изменения приобретут необратимый харак- тер и станут полезными при наличии достаточного уровня общения и эмпатии в организации.

Часть V
МАСШТАБИРОВАНИЕ

ГЛАВА 14
Масштабирование:
критические точки
Эта глава посвящена способам выявления и преодоления трудностей, возника- ющих на основных этапах жизненного цикла организаций. На первый взгляд может показаться, что проще все свести к идее «корпоративных devops-прак тик», как обычно поступают многие, когда идет речь о методологиях devops, которые не используются в стартапах и небольших компаниях. Но это было бы слишком просто, хотя подобные devops-практики и включают некоторые специфичные для корпораций моменты, которые будут рассмотрены в настоящей главе. Гораздо лучше было бы описать процесс изменения компании с течением времени, будь то рост и развитие стартапа или разделение крупной организации на две отдельные компании. С помощью масштабирования описываются эволюция, рост и продви- жение организации как единого объекта на всех этапах ее жизненного цикла.