Джин Ким - Руководство по DevOps

Здесь есть возможность читать онлайн «Джин Ким - Руководство по DevOps» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2018, ISBN: 2018, Издательство: Манн, Иванов и Фербер, Жанр: Интернет, Базы данных, Прочая околокомпьтерная литература, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Руководство по DevOps: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Руководство по DevOps»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Профессиональное движение DevOps зародилось в 2009 году. Его цель — настроить тесные рабочие отношения между разработчиками программного обеспечения и отделами IT-эксплуатации. Внедрение практик DevOps в повседневную жизнь организации позволяет значительно ускорить выполнение запланированных работ, увеличить частоту релизов, одновременно повышая безопасность, надежность и устойчивость производственной среды. Эта книга представляет собой наиболее полное и исчерпывающее руководство по DevOps, написанное ведущими мировыми специалистами.

Руководство по DevOps — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Руководство по DevOps», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Широкое распространение результатов анализа ошибок и поощрение знакомства с ними увеличивают суммарные знания компании. Кроме того, среди организаций, занимающихся онлайн-услугами, все более распространенными становятся публикации разборов инцидентов, повлиявших на клиентов. Это часто сильно увеличивает прозрачность работы компании для внутренних и внешних клиентов и, в свою очередь, повышает доверие к нам.

Стремление проводить как можно больше совещаний по разбору ошибок привело компанию Etsy к некоторым проблемам: за четыре года в базе организации накопилось огромное число заметок со встреч. Искать информацию, сохранять новые данные и работать с базой знаний стало очень трудно.

Чтобы справиться с проблемой, в компании придумали инструмент под названием Morgue, позволяющий легко фиксировать аспекты каждого сбоя, например его MTTR и степень серьезности, лучше работать с разными часовыми поясами (это стало важно, потому что многие сотрудники Etsy начали работать удаленно) и включать в отчеты другие данные, например текст в формате Markdown, изображения, теги и историю.

Приложение Morgue было разработано для того, чтобы команде было легко фиксировать:

• возникла ли проблема из-за запланированного или незапланированного инцидента;

• кто ответствен за разбор ошибок;

• важные логи IRC-чата (особенно важно для проблем, возникших в три часа ночи, когда точное фиксирование деталей может не произойти);

• важные тикеты JIRA для корректирующих действий и дедлайны по ним (эта информация особенно важна для менеджмента);

• ссылки на форумные посты клиентов (где клиенты жалуются на проблемы).

После разработки и использования Morgue число фиксируемых разборов в Etsy сильно увеличилось по сравнению с тем временем, когда они использовали страницы специальной вики, особенно для инцидентов P2, P3 и P4 (то есть инцидентов с низким уровнем серьезности). Этот результат подтвердил гипотезу, что если документировать разбор ошибок с помощью инструментов типа Morgue станет проще, то больше специалистов начнут записывать и детализировать результаты совещаний, и накопленный опыт организации увеличится.

Эми Эдмондсон, профессор управления и менеджмента Гарвардской школы бизнеса и соавтор книги Building the Future: Big Teaming for Audacious Innovation, пишет:

Путь решения проблемы, не обязательно требующий больших затрат времени и денег, — избавиться от предрассудков в отношении ошибок. Эли Лилли делает это еще с ранних 1990-х: она устраивает «вечеринки неудачников», чтобы отметить умные, высококачественные научные эксперименты, закончившиеся неудачей. Эти вечеринки обходятся недорого, а перераспределение ценных ресурсов — а именно ученых — на новые проекты раньше, чем обычно, может сэкономить сотни тысяч долларов, не говоря уже о возможных стимулах для новых открытий.

Уменьшите стандартные отклонения, чтобы улавливать слабые сигналы о возможных сбоях

Когда организации учатся эффективно диагностировать и решать проблемы, то, чтобы не останавливаться в развитии, они неизбежно расширяют понятие того, что считать проблемой. Для этого нужно научиться усиливать слабые сигналы о возможных неполадках. Например, как было описано в части IV, к тому моменту, когда компания Alcoa смогла существенно сократить количество несчастных случаев на производстве, Пол О’Нил, CEO [147]Alcoa, начал получать отчеты не только о реально произошедших несчастных случаях, но и о потенциально аварийных ситуациях.

Доктор Стивен Спир резюмирует достижения О’Нила, отмечая: «Хотя все началось с проблем безопасности труда, в компании быстро обнаружили, что эти проблемы отражали общее невежество в отношении процессов производства, и эта невежественность проявлялась в других проблемах, связанных с качеством, своевременностью работы и количеством брака».

Когда мы работаем в сложных системах, необходимость усиливать слабые сигналы очень важна, чтобы избежать катастрофических последствий. Прекрасный пример — как NASA использовала сигналы о неполадках в эпоху космических шаттлов. В 2003 г., на шестнадцатый день полета космического шаттла Columbia, он взорвался при входе в атмосферу. Сейчас известно, что это произошло из-за того, что во время взлета от внешнего топливного бака оторвался кусок теплоизоляционной пены.

Незадолго до входа шаттла в атмосферу несколько инженеров NASA среднего звена сообщили об этом инциденте, но их не услышали. Во время послестартового анализа инженеры заметили на видеозаписи, что отпавший кусок теплоизоляции повредил теплоизоляцию на крыле, и оповестили об этом менеджеров NASA, но им ответили, что проблемы с теплоизоляцией бывают часто. Смещение изоляционной пены повреждало шаттлы и во время предыдущих запусков, но это никогда не приводило к авариям. Считалось, что это проблема технического обслуживания, не стоит из-за нее принимать специальных мер.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Руководство по DevOps»

Представляем Вашему вниманию похожие книги на «Руководство по DevOps» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Николь Форсгрен - Ускоряйся! Наука DevOps
Николь Форсгрен
Отзывы о книге «Руководство по DevOps»

Обсуждение, отзывы о книге «Руководство по DevOps» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x