Руководство по DevOps - [2]
Мне повезло: с 1999 г. я изучал организации, использующие высокопроизводительные технологии. Вот один из моих первых выводов: решающее значение для успеха имеет перекрестное взаимодействие функциональных групп, занимающихся эксплуатацией, информационной безопасностью и разработкой. Я до сих пор помню, как впервые осознал масштабы нисходящей спирали, в которую заключена деятельность этих групп с их противоположными задачами.
Это было в 2006 г., и мне тогда представилась возможность поработать целую неделю с группой, решавшей отданные на аутсорсинг IT-задачи, поставленные крупной службой резервирования и продаж авиабилетов. Участники группы рассказали об увеличивающихся негативных последствиях ежегодных крупных обновлений программного обеспечения: каждый раз наступал настоящий хаос, шквал неудобств как для исполнителей, так и для заказчика. Из-за простоев у пользователей им приходилось выплачивать немалые компенсации согласно договорам по сервисному обслуживанию. Увольнялись наиболее способные и опытные работники, так как, опасаясь потерять прибыль, компания вынуждала их наращивать темп, выполнять массу незапланированной работы и «тушить пожары». У оставшегося персонала не хватало сил справляться со все возрастающим потоком требований заказчиков, желавших исправления ошибок. От расторжения сервисного контракта компанию спасали только героические усилия менеджеров среднего звена, и все были уверены: у контракта нет будущего, его не продлят на следующие три года.
Отчаяние и безнадежность подтолкнули меня к тому, чтобы начать нечто вроде наступательной операции. Разработка всегда рассматривалась как часть стратегии, а эксплуатация — тактики. Нередко они частично или даже полностью отдавались на аутсорсинг, чтобы лет через пять вернуться обратно, еще более усложнившимися.
Многие годы мы размышляли, как улучшить ситуацию. Вспоминаю, как на конференции Velocity Conference 2009 с интересом следил за обсуждением фантастических результатов, достигнутых благодаря использованию принципов бизнес-архитектуры, технических методов и норм корпоративной культуры в совокупности. Теперь эта методика известна нам как DevOps. Тогда я неподдельно взволновался: передо мной наметился путь выхода из создавшейся ситуации — его-то мы так долго искали. Стремясь распространить новое знание как можно шире, я и решил выступить соавтором The Phoenix Project. Вы запросто можете представить себе, какое огромное внутреннее удовлетворение я испытал, видя видя отзывы людей о том, как книга помогла им придти к озарению и воскликнуть: «Ага!»
Мое личное «Ага!» впервые раздалось в 2000 г., в стартапе, который был моим первым местом работы после окончания обучения. Некоторое время нас, технических специалистов, было только двое. Поэтому мне приходилось заниматься всем: сетями, программированием, поддержкой пользователей, системным администрированием. Мы выпускали ПО, размещая его на FTP прямо с рабочих станций.
В 2004 г. я перешел в консалтинговую компанию ThoughtWorks, где впервые принял участие в работе над проектом в составе команды численностью около 70 человек. Я входил в группу из восьми инженеров, занимавшуюся развертыванием нашей программы в среде, приближенной к производственной. Поначалу задание вызывало у нас сильный стресс. Но спустя несколько месяцев мы перешли от режима работы вручную, занимавшего около двух недель, к автоматическому разворачиванию продолжительностью всего один час. Теперь можно было за доли секунды откатывать конфигурации назад и вперед, используя технику «Blue-Green разворачивания» в рабочее время[3].
Проект породил массу идей, изложенных как в этой книге, так и в другой — «Непрерывное развертывание ПО»[4]. Они убедили меня и многих моих коллег: с какими трудностями нам ни пришлось бы сталкиваться, мы способны действовать с максимальной отдачей и помогать людям.
Для меня это была целая цепь событий. В 2007 г. я работал в проекте по миграции дата-центра совместно с несколькими Agile-командами. Я завидовал их высокой продуктивности, умению выполнять большой объем работы за ограниченное время.
Получив следующее задание, я приступил к эксперименту по внедрению методики канбан в работу группы эксплуатации и увидел: группа стала быстро меняться. Позже, на конференции Agile Toronto 2008, я представил свой доклад в IEEE[5] на эту тему, но, к сожалению, он не получил широкого отклика в Agile-сообществе. Мы начали создавать административную группу для системы Agile, но тут я переоценил значение человеческого фактора.
Увидев на Velocity Conference 2009 презентацию Джона Олспоу и Пола Хаммонда «10 развертываний в день», я убедился: у меня есть единомышленники. Поэтому я решил организовать первую конференцию DevOpsDays и так случайно создал новый термин — DevOps.
Энергетика мероприятия была уникальной. Участники благодарили меня, утверждая, что конференция изменила их жизнь к лучшему. Так я осознал степень воздействия концепции DevOps и с тех пор неустанно продвигаю ее.
В 2008 г. я продал свою консалтинговую компанию, специализировавшуюся на внедрении крупномасштабных устаревших решений в области управления конфигурациями и мониторинга (Tivoli). Тогда же я впервые встретил Люка Каниса (основателя компании PuppetLabs). Люк выступал с презентацией о Puppet на проводившейся издательством O’Reilly конференции по конфигурационному управлению (CM) на основе открытого исходного кода.
Билл – IT-менеджер в компании Parts Unlimited. Утро вторника, по дороге в офис его застает врасплох звонок от генерального директора.Новая IT-инициатива компании под кодовым называнием «Проект Феникс» имеет критическое значение для Parts Unlimited, но проект явно выходит за рамки возможностей бюджета и очень сильно не укладывается в сроки. Генеральный директор хочет, чтобы Билл уладил все проблемы за 90 дней, или же весь отдел Билла будет уволен. С помощью перспективного члена команды и своей мистической философии Трех Путей Билл начинает видеть, что работа в IT имеет гораздо больше общего с работой завода, чем он когда-либо мог представить.
Где и как искать инопланетян? Идея внеземной жизни завораживала человечество задолго до начала освоения космического пространства. Джон Уиллис, астроном и популяризатор науки, приводит пять наиболее реалистичных сценариев поиска инопланетных живых существ в нашей Галактике. Описывая последние достижения в изучении космоса — результаты космического телескопа «Кеплер», исследование Марса с помощью марсохода «Кьюриосити», пролет около Плутона зонда «Новые горизонты» и многие другие, — Уиллис предоставляет читателям возможность самим выбрать подходящий способ обнаружения внеземной жизни.
В книге рассказывается история главного героя, который сталкивается с различными проблемами и препятствиями на протяжении всего своего путешествия. По пути он встречает множество второстепенных персонажей, которые играют важные роли в истории. Благодаря опыту главного героя книга исследует такие темы, как любовь, потеря, надежда и стойкость. По мере того, как главный герой преодолевает свои трудности, он усваивает ценные уроки жизни и растет как личность.
Во всякой уважающей себя книге должно быть предисловие.Но ведь это не совсем настоящая книга! Здесь нет выдуманных героев и сочиненных ситуаций, удачных рецептов, и даже отсутствуют рекомендации, как выйти замуж за олигарха!Почему стоит прочитать эту книгу? Прежде всего потому, что она и о вас.О нашей общей жизни, в которой много чего есть, но больше всего, конечно, любви. Так что это записки о любви, реальные записки, а не выдуманные.Эту самую жизнь я стала записывать на страницах Живого Журнала. Для себя и моих близких.
Тема форума Флибуста через i2p, TOR и VPN (инструкции по установке и запуску для «чайников»). v. 1.0ВНИМАНИЕ!Все приведённые ниже настройки не обеспечивают вашу полную анонимность в сети, и предназначены исключительно для доступа к книгам на Флибусте.Информацию по безопасной работе с запрещенными сайтами это руководство не дает, это не является профилем библиотеки.Берегите себя.
Когда в нашей жизни появился Интернет, миллионы людей на планете подумали, что он откроет всем мир колоссальных возможностей и что это величайший цивилизационный сдвиг со времен промышленной революции… Однако что мы знаем о темной стороне Сети?Раскрыть глаза человечеству взялся Эндрю Кин, которого в Кремниевой долине назвали Антихристом за резкую критику плутократов вроде Марка Цукерберга, зарабатывающих несметные богатства на использовании персональных данных обычных пользователей. Кин рассказывает, как владельцы Google, Facebook, Twitter, Instagram, прочих «цифровых гигантов», действуя по принципу «Победитель получает всё», усугубляют безработицу и экономическое неравенство, как интернет-бизнес породил целую индустрию добычи и переработки наших с вами личных данных.Детально воссозданная технологическая и экономическая картина Интернета будет интересна всем, кто хочет пользоваться его благами с минимальным ущербом для собственной безопасности.
Системное, компактное и хорошо структурированное руковод ство по всем аспектам функционирования корпоративных сайтов. Книга обобщает богатый практический опыт ее авторов (более 700 успешных проектов в сфере веб-разработок и сотни печатных и электронных публикаций). На страницах книги вы найдете множество рекомендаций, примеров, методик и контрольных списков, которые позволят сделать ваш веб-сайт мощным бизнес-инструментом.Книга адресована директорам по маркетингу и другим специалистам, в чьи обязанности входит управление корпоративными веб-сайтами.В качестве важного дополнения к настояшему изданию рекомендуем сайт www.webdevelopment.ru, на котором вы можете оставить свои комментарии, ознакомиться с дополнительными материалами, задать вопросы, пообщаться с авторами.
В книге рассказывается история главного героя, который сталкивается с различными проблемами и препятствиями на протяжении всего своего путешествия. По пути он встречает множество второстепенных персонажей, которые играют важные роли в истории. Благодаря опыту главного героя книга исследует такие темы, как любовь, потеря, надежда и стойкость. По мере того, как главный герой преодолевает свои трудности, он усваивает ценные уроки жизни и растет как личность.