Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 377
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
346
Часть V. Масштабирование растут с течением времени. Эти барьеры влияют на подход к различным кри- тическим точкам, которые могут возникать на протяжении жизненного цикла организации.
Иногда нужно пересматривать текущие процессы и возвращаться обратно. Порой нужно быть медлительными и осторожными, а бывает, что нужно быть быстрыми и динамичными. Успех приходит в результате непрерывной практики и обучения на ошибках.
Успешное масштабирование — это искусство и наука принятия решения о том, когда и как нужно изменить направление (в случае необходимости), чтобы успеш- но перемещаться в постоянно изменяющейся среде. Как и в случае с открытым восхождением, отсутствуют размеченные красочные маршруты, которые будут направлять вас в конкретной ситуации. Нужно начать с повышения необходимых навыков на уровне отдельных людей, команд и организации в целом, а затем при- менить базовые принципы эффективных devops-методик независимо от сложно- сти и размеров организации.
1 ... 29 30 31 32 33 34 35 36 ... 39
ГЛАВА 15
Масштабирование: заблуждения
и устранение проблем
В этой главе будут рассмотрены некоторые наиболее часто встречающиеся про- блемы масштабирования и способы их устранения. Также будут рассмотрены вопросы, относящиеся как к обычным сотрудникам, так и к менеджерам. Советы, представленные в данной главе, помогут в разрешении проблем работникам, вы- полняющим разные роли на предприятии.
Заблуждения, связанные с масштабированием
Как упоминалось в предыдущей главе, организации более заинтересованы в мас- штабировании, чем просто в сохранении статуса большой компании или во вне- дрении некоторых devops-практик уровня предприятия.
Некоторые команды никогда не смогут работать вместе
Очень часто движение devops возникает как результат конфликта между команда- ми разработчиков и эксплуатации из-за отсутствия взаимопонимания. Обычно ко- манды попадают в состояние конфликта из-за повышенной напряженности и на- копившихся недоразумений. Как упоминалось в части II, не следует рассматривать конфликты как негативные явления. Конфликт — это хороший признак здоровой организации, поэтому не стоит его бояться или избегать. Важно не допускать взаимных конфликтов между командами. Если межличностное урегулирование подразумевает примирение по принципу «один на одни», то групповое урегули- рование конфликта — более сложный процесс. Следует научиться корректировать внутригрупповые связи и процессы, приведшие к сбоям.
На первых этапах бывает очень трудно урегулировать конфликты, поскольку команды заново учатся взаимодействовать друг с другом. Для восстановления доверительных отношений требуется много времени и усилий. Одно неловкое действие может свести на нет все предыдущие попытки.
348
Часть V. Масштабирование
Ниже приведены основные модели поведения, которые нужно отслеживать.
Критика
Переход на личности, диктуемый особенностями характера.
Проявление неуважения
Заявления или поведение, обусловленные позицией превосходства.
Защитное поведение
Заявления или поведение, продиктованные соображениями самозащиты.
Замалчивание проблемы
Эмоциональное отчуждение, мешающее общаться с людьми
Огульные обвинения
Заявления, содержащие упреки типа «они всегда», «они никогда» или «мы всегда/никогда».
В командах, постоянно противопоставляющих себя другим, зачастую возникают проблемы самоопределения. Команды должны иметь одно общее видение и опре- деление успеха. Если одна группа почувствует, что ее цели недостижимы из-за дефицита информации и прозрачности, относящейся к другим группам, в этом случае вторая группа может оказывать эмоциональное давление. Это в свою оче- редь способствует усугублению и так напряженных отношений между командами.
В случае распределенных команд проблемы будут усугубляться. Если в противо- речие вступают различные приоритеты и цели, связанные с достижением успеха, конфликт между распределенными группами будет усугубляться и для его разре- шения потребуется больше усилий. Процесс принятия решений в таких группах должен быть прозрачен и понятен для всех членов команды.
Как показывают исследования, если сотрудники различных подразделений регу- лярно наносят визиты друг другу, между ними налаживаются дружеские связи, укрепляются договорные отношения и вырабатываются способы взаимодействия и сотрудничества
1
. Менеджеры по возможности должны содействовать проведе- нию таких встреч, чтобы на основе прозрачности обеспечить совместную работу команд. Людям не нравится, когда их ставят перед фактом принятия решений, ко- торые оказывают на них непосредственное влияние, даже если они удовлетворены результатами принятия таких решений.
Серьезный конфликт, отражающийся на результатах работы, обычно является следствием слияния двух компаний. Чтобы искоренить принцип противопостав- ления команд, в процесс продвижения к цели должны быть вовлечены влиятель- ные лица из обеих компаний.
1
Pamela J. Hinds and Catherine Durnell Cramton, «Situated Coworker Familiarity: How Site Visits
Transform Relationships Among Distributed Workers», Organization Science 25, no. 3 (2014).
Глава 15. Масштабирование: заблуждения и устранение проблем
349
Подобная ментальность присуща людям, использующим свою независимость и знания в целях засекречивания своей работы. Им нравится быть в роли единст- венной критической точки или уязвимого места в процессе передачи знаний. Эти люди считают себя настолько ценными, что компания, по их мнению, никогда от них не откажется. Такой подход может негативно отразиться на отношениях с ана- логичными компаниями. В этих случаях рекомендуется принимать меры, направ- ленные на передачу информации и корректировку взаимоотношений, включая устранение недоверия между отдельными сотрудниками и компанией.
Внедрение изменений невозможно
без одобрения начальства
Менеджер всегда оказывает достаточно большое влияние на своих непосредствен- ных подчиненных и на эффективность их работы. Если со стороны высшего руко- водства отмечается сильное давление на сотрудников, менеджер выступает в роли
«зонтика»,
1
то есть защищает своих подчиненных от грязи, которая выливается на них в процессе работы.
Если руководство ставит слишком высокие требования, менеджер может либо защитить свою команду от возможных неприятностей, либо просто слить на них все непомерные запросы начальства (то есть выступить в роли «сливной воронки для нечистот»).
Менеджер должен делать все от него зависящее, чтобы вдохновить свою команду, предоставив ей максимальную свободу действий по экспериментам с инструмен- тами, рабочими потоками и практиками, применяемыми в команде. В зависимости от культуры организации менеджеру легче убедить своих подчиненных в том, что текущие результаты могут достигаться за счет использования новых, более эффективных инструментов или рабочих потоков. Менеджер обязан делать все возможное для защиты своей команды от скептиков и поиска оптимальных спо- собов работы с ними.
Наш бюджет не предусматривает набор
новых специалистов, в связи с чем внедрение
devops-методик на данном этапе невозможно
Процесс переориентирования культуры небольших или быстро развивающих- ся организаций в сторону использования devops-практик происходит проще в случае подбора персонала с соответствующим опытом и мировоззрением. Тем
1
Эта фраза принадлежит Тодду Джексону (Todd Jackson), бывшему управляющему группой товаров Gmail в Google. Дословно звучит так: «Менеджер может быть сливной воронкой для нечистот или зонтиком от дерьма».
350
Часть V. Масштабирование не менее не каждая компания решится на прием большого количества новых сотрудников, если вообще пойдет на такой шаг. К счастью, внедрение devops- методик возможно и без привлечения новых сотрудников, являющихся «10x devops-инженерами».
Выработайте единое понимание целей
Чтобы каждый сотрудник компании проникся идеей devops, следует убе- диться в том, что у всех работников сформировано одинаковое представ- ление об этой методике. Менеджер должен уметь не только донести до коллектива предмет изменений, но и объяснить причину, вызвавшую не- обходимость этих изменений. Это особенно касается больших компаний, имеющих тенденцию к реорганизации. В таких компаниях люди зачастую с подозрением относятся к изменениям, для них это звучит как что-то не- существенное или как пустые декларации. Менеджер должен убедить свою команду в том, что речь идет о конкретных изменениях, направленных на получение практических результатов.
Создайте условия и возможности для обучения
Как уже упоминалось в главе 8, старого системного администратора можно обучить новым трюкам. Трансформация devops подразумевает освоение новых программных и технических навыков, таких как составление безуп- речного постмортема и работа с Docker. Убедитесь в том, что сотрудники организации могут получить все необходимые навыки. Также обеспечьте создание обучающей среды и личностный рост каждого сотрудника орга- низации.
Сформируйте среду для успешного внедрения devops-принципов
Для внедрения изменений следует создать условия, при которых людям будет интересно выполнять эту работу. Чтобы сотрудники больше обща- лись между собой или занимались наставничеством, менеджер должен закрепить эти навыки в матрице навыков или внести в план служебного роста. В целях пресечения грубого поведения следует поощрять сотруд- ников, которые сообщают о таких поступках. Агрессивное и оскорби- тельное поведение недопустимо и должно наказываться менеджером.
Невозможно создать такую среду, в которой совмещались бы хорошие и плохие работники. Если менеджер не борется с негодяями, то, скорее всего, он активно сопротивляется внедрению devops-среды, основанной на сотрудничестве.
Если нужно изменить существующую среду, привычки и поведение людей, следует действовать постепенно. Нужно быть уверенным в наличии четких целей, возмож- ностей для обучения и атмосферы доверия, эмпатии и сотрудничества.
Глава 15. Масштабирование: заблуждения и устранение проблем
351
Устранение проблем, связанных
с масштабированием
Универсального решения по устранению проблем, возникших при выполнении масштабирования, не существует. В данном разделе представлены общие сценарии развития событий в организациях в процессе их роста и развития на протяжении жизненного цикла.
Менеджмент рекомендует придерживаться X,
не видя пользы от devops
При рассмотрении компании Target в предыдущей главе говорилось о том, что на определенном этапе развития компании менеджмент дает добро на внедрение изменений, которые имели бы более продолжительный эффект в рамках всей организации. Тем не менее не стоит ожидать одобрения этих действий с самого начала. Рекомендуется начать с одной команды, дать ей время на эксперименты и посмотреть, как будет продвигаться дело. Положительные результаты внедрения изменений будут служить ценным примером для других команд.
Если проблема связана с топ-менеджментом, попросите вашего непосредственного менеджера помочь в вопросе внедрения изменений. Эта помощь может заключать- ся в следующем:
разобраться с ограничениями непосредственно на рабочем месте;
вести переговоры с другими менеджерами от вашего имени;
позволить вам проводить эксперименты в команде;
защищать вас от любых негативных последствий.
Если ваш непосредственный менеджер не видит пользы от внедрения devops, вам будет сложнее влиять на ход изменений. В этом случае можно найти союзников в своей команде. Если менеджер настаивает на использовании инструмента Х, сможете ли вы применять его наравне с новым инструментом или методикой Y, чтобы через некоторое время сравнить результаты? Сможете ли вы влиять на вашего менеджера и обсуждать с ним темы эффективности изменений и их пре- имуществ?
Недостаточные ресурсы команд
Если команды систематически не выполняют задания или не соблюдают норма- тивные сроки при достаточно реальных планах и требованиях, возможно, над по- ставленными задачами или проектами работает мало людей. В этом случае следует произвести переоценку рабочей загрузки и сроков выполнения работ. Вариантом выхода из создавшейся ситуации может быть перераспределение сотрудников
352
Часть V. Масштабирование между проектами или пересмотр календарного планирования, что реально позво- лит данной команде завершить работу в установленные сроки.
Возможно, придется нанять в команду больше людей, особенно на стадии роста.
При этом следует учитывать, что на стадии спада, сопровождающейся сокраще- нием количества штатных сотрудников, не всегда уменьшается объем работ или рабочая нагрузка. С целью сокращения расходов прежний объем работ выполня- ется меньшим количеством людей, что на определенном этапе может негативно отразиться на качестве работ и привести к выгоранию персонала. Поэтому нужно соизмерять свои ожидания с реальностью.
Чтобы при том же количестве сотрудников достигались более эффективные результаты труда, люди должны работать не интенсивнее, а интеллектуальнее.
Вместо того чтобы тратить больше времени на выполнение большего объема работ, можно усовершенствовать оборудование и технологии. Следует обсудить с члена- ми команды производственный процесс и инструменты, используемые в работе, продумать способы повышения их эффективности с целью экономии времени и усилий. Поиск оптимальных решений можно вести за пределами компании, учитывая вместе с тем мнения и предложения членов команды. Опрос сотрудни- ков обычно занимает много времени и усилий, особенно если люди не привыкли высказывать свои идеи и мнения. Как бы там ни было, но благодаря таким иссле- дованиям можно получить очень полезную информацию.
Принятие необоснованных решений
Болевой точкой в процессе роста и развития организаций является осознание того, что процессы принятия решений отнимают много времени и усилий, а результаты не всегда соответствуют ожиданиям (руководство решило попробовать Х, но стало не лучше, а еще хуже). В небольшой организации, когда весь инженерный отдел помещался в одной комнате, решения принимались быстро и легко. Когда компа- ния расширяется до нескольких подразделений, разбросанных по всему миру, про- цесс принятия решений превращается в затяжную рутину. Ниже описаны способы решения этой проблемы.
Исследование процессов
По мере роста организации усиливается путаница в вопросах ответствен- ности за те или иные проблемы. Если над проектом работает несколько команд, проблемы зачастую остаются незамеченными и никто не несет за них ответственности. Иногда оспаривание командами своей вины в по- явлении проблемы может привести к конфликтам. Последняя ситуация особенно отрицательно сказывается на эффективности процесса принятия решений. Многочисленные споры всегда затрудняют возможность что-либо решить. С другой точки зрения, любые спускаемые сверху решения, которые принимаются без особого оспаривания, как правило, не всегда устраивают сотрудников.