Философия DevOps. Искусство управления IT - Дженнифер Дэвис, Кэтрин Дэниелс (2016)
-
Год:2016
-
Название:Философия DevOps. Искусство управления IT
-
Автор:
-
Жанр:
-
Серия:
-
Язык:Русский
-
Перевел:Александр Сергеев
-
Издательство:Питер
-
Страниц:27
-
ISBN:978-5-496-02555-3
-
Рейтинг:
-
Ваша оценка:
DevOps – это не элементарно комплект техник, это философия. Создатели, зацикленные на юзерах, обязаны уделять забота помощи и ее запросам. Сисадмины обязаны говорить о дилеммах продукта и заносить личный лепта в совершенствование процесса работы. Но налаживание связей изнутри фирмы – это только 1-ый шаг. Дабы продукт стал обычным и комфортным, будет необходимо вложить время и ресурсы в его доработку. Форма сквозь центральную службу, внедрение обычным копированием, недоступность наружных зависимостей, продуманные метрики взамен мусора в логах – вот только доля задач, которые будет необходимо улаживать на данном пути.
Книжка «Философия DevOps» познакомит вас с техническими, культурными и управленческими качествами devops-культуры и дозволит осуществить работу так, дабы вы получали наслаждение от разработки, помощи и применения программного обеспечения.
Философия DevOps. Искусство управления IT - Дженнифер Дэвис, Кэтрин Дэниелс читать онлайн бесплатно полную версию книги
Обеспечение правильной и безопасной страховки требует от страхующего напарника как понимания используемых инструментов и процессов, так и обеспечения постоянной связи со скалолазом, выполняющим восхождение. Восходитель должен надежно прикрепить страховочный трос к карабину. Страхующему напарнику нужно убедиться в том, что страховочное устройство надежно закреплено с помощью карабина. Между скалолазами устанавливаются доверительные отношения, но прежде чем приступать к восхождению, нужно еще раз все проверить.
При восхождении используется набор словесных ключей, позволяющих проверить готовность к процессу восхождения. Сначала восходитель спрашивает у напарника: «На страховке?» Напарник отвечает: «На страховке». Затем восходитель говорит: «Подъем!», сигнализируя о готовности к началу восхождения. И наконец, напарник подтверждает осведомленность о готовности восходителя, произнося слово «подъем».
Для обеспечения работоспособности этого пакта применяются следующие принципы:
• общие четко сформулированные цели;
• непрерывное общение;
• динамическая настройка и коррекция понимания.
Как будет показано в следующих разделах, соблюдение этих принципов необходимо как для внедрения devops на рабочем месте, так и для успешного восхождения на горную вершину.
Пример devops-пакта
Представьте себе, что два сотрудника компании Sparkle Corp работают в разных командах. Сотрудник по имени Дженераль является старшим разработчиком, обладает множеством рабочих навыков и работает в компании Sparkle Corp уже два года. Джордж работает в отделе техподдержки, обладает некоторыми рабочими навыками и является новичком в компании Sparkle Corp.
Команды, в которых работают эти два сотрудника, поддерживают глобальное сообщество людей, использующих сайт компании Sparkle Corp для реализации своих творческих начинаний. Общая цель, стоящая перед этими командами, заключается во внедрении нового средства, которое увеличивает ценность сайта компании для конечных пользователей, не оказывая на него негативного влияния.
Обладая большим опытом работы в компании, Дженераль дает четкие указания Джорджу об ожиданиях, ценностях и процессах, имеющих место в компании Sparkle Corp. В свою очередь Джордж может в любой момент обратиться к Дженераль с просьбой о помощи или в случае непонимания какого-либо производственного нюанса. Прежде чем перейти к следующему этапу производственного процесса, Дженераль и Джордж контролируют результаты работы друг друга. Подобная проверка является примером модели «доверяй, но проверяй», используемой при описании процесса скалолазания.
Как Дженераль, так и Джорджу присуще понимание общих целей:
• внедрение нового инструмента, увеличивающего ценность для заказчиков компании Sparkle Corp;
• поддержка безопасности и доверия при осуществлении взаимного обмена информацией.
В изолированной среде, не использующей принципы devops, понимание общих целей отсутствует. Это может привести к тому, что, например, Дженераль попытается приступить к кодированию, не убедившись в том, что Джордж понял суть требований. В этом случае совместная работа возможна, но без обмена информацией о намерениях шансы на успех уменьшаются.
Безусловно, в любой организации могут возникать неожиданные проблемы или препятствия, но при наличии общего понимания целей каждый сотрудник является частью пакта, а предпринимаемые действия направлены на выполнение текущего «ремонта». Мы «ремонтируем» наше недопонимание, связанное с выбором исполнителей работ по разработке конкретного инструмента или сроков выполнения работы. Мы устраняем ошибки, влияющие на наше понимание предполагаемого поведения программного обеспечения. Мы «ремонтируем» процессы и сопровождающую документацию, если дела в производственной сфере идут не так, как ожидалось.