DevOps пиактики можно внедрять даже при малом количестве серверов.
К тем, кто говорит про кризис:
я знаю компании, где помимо чуваков, которые зпнимаются внедрением девопс практик, есть еще и отдел эксплуатации, т.е. обычные админы.
Например, Яндекс.
Я просто хотел понять, что публика лора понимает под понятием 'методология девопс'
inb4 маркетинговый буллшит
Как я понимаю про яндекс: у них отдел админов для основных проектов, где сервера считаются тысячами, где много именно административных задач. Они создают средства администрирования для всех. А девопс - для маленьких проектов из 3х человек, где пара сотен серверов. Причем эти девопс уже используют наработки отдела эксплуатации (инфраструктуру администрирования) и допиливают конкретный проект, скажем, на hadoop. Они и поадминить и покодить успевают.
Ну я тоже не совсем верно выразился. Дело в количестве сущностей. Если их не много, то это просто бессмысленное усложнение системы. А так девопс очень годный подход.
Когда разработчик дает администратор и говорит: 'задеплой, сантехник ит', администратор матерится на этих програмистов, которые вечно пишут какую-то шнягу, которую непонятно как поддерживать, мониторить и тд. К тому же полагается она на костыли, о которых, естественно, только разработчик(и) в курсе.
В итоге имеем 502 на проде, спящему админу летят смски, он пытается понять, что не так, дозвониться разработчику, который в отпуске и т.д.
В то же время со стороны администратора возможна такая же ситуация, когда бекенд использует системный вызов, который ломается после обновления, или изменение правил файрвола, например.
В моем понтмании, de ops - набор правил и практик, которые помогают избегать таких случаев, а также повышать качество коммуникации между этими 2 подразделениями.
Схема ответственности, которую вижу я:
опсы отвечают за работоспособность ос, сети, и остальных системных вещей
Девопсы - за работоспоспобномть приложения, т.к. они конкретное приложение знают лучше (сюда же входят тулзы для развертывантя и мониторинга)
Это легкое чтиво, на 170 страниц малого формата, литературный стиль. Мягко говоря, это не похоже на серьезную литературу про IT.:) Читать легко, но какая нафиг «Идеология Devops»? Идеология - это 30 томов Ленина по 500 страниц мелким текстом. Или хотя бы книги от Cisco Press.
И чувак не сам пришел, его пришли в связи с сокращением бюджета по всей компании. :) Так что кто там писал выше про экономию на персонале?) Возможно, он был даже прав.)
Книжка может и веселая, но ни о чем. Я сначала с интересом читал, а потом понял, что реально про администрирование там ничего. Да и чувак в итоге уволился. Ищешь хорошую книжку - the practice of system and network administration.
Фундаментальной... ты нигде не пересидел (в учебном заведении)? Скажи, есть «фундаментальные» труды для сантехников? Админство, девопс и все прочее - это прикладные, технические-инженерные профессии, а не rocket science. Конечно, читать книги полезно. Но кто сказал, что их нет? Отлично публикуются на западе и попадают на торренты. Про DevOps см. на amazon.
На случай, если ты забыл, что сам написал двумя постами выше.:)
Есть книга The Phoenix Project - вот в ней рассказывается про чувака, который пришел к devops в итоге.
Меня просто заинтересовала книгу на тему DevOps, потому что это новое направление.
Чем не фундаментальная книга?
Меня не очень заинтересовала. Во-первых, я это знаю, а во-вторых, это не фундаментально просто потому, что профилировать приходится весь стек приложений, а не одну программу и ОС. Хотя с другой стороны, лет десять назад я бы, наверное, с большим интересом ее прочел...
это не фундаментально просто потому, что профилировать приходится весь стек приложений, а не одну программу и ОС. Хотя с другой стороны, лет десять назад я бы, наверное, с большим интересом ее прочел...
У такой литературы нет давности, ты, видимо, просто не в теме и книгу в глаза не видел
Нет, почему же? Раз хвалят, я скачал и посмотрел. Вижу, что все знакомо. Десять лет назад было бы в новинку. Так что речь шла не о давности, разве что о моей.:) В свою очередь я тебе предлагаю открыть первое издание Олиферов и посмотреть, насколько устаревает такая литература.
Или вот пример лучше. У меня на столе переводное издание Архитектура Компьютера Таненбаума, 5ое издание, 2007 год.
Рассматривается Pentium 4. Подробно описаны процессорные команды этого 32 битного процессора. Фундаааментально! И рассказывается о перспективном процессоре будущего - Itanium.
Короче, подробно описаны 32битные регистры, но ничего нет про виртуализацию ОС. В том числе и про vmx регистр.
Ничего нет про SATA шину. Не говоря уже об SSD, когда принцип записи на диск просто поменялся.
Вот она фундаментальность твоей книжки. Очень скоро ее будут читать, как мануал к ipchains.
Т.е. ты пришел, прочел последний комент и сделал фейспалм? Сразу видно - умен!) Попробуй сначала подумать, что такое фундаментальность в контексте треда.
Десять лет назад было бы в новинку. Рассматривается Pentium 4. Подробно описаны процессорные команды этого 32 битного процессора. Фундаааментально! И рассказывается о перспективном процессоре будущего - Itanium.
Ну вот у тебя уже файлы не сходятся, так что неубедительно. Книга вышла в 2013, принципы и методы нарабатывались годами и они не меняются, так что ты точно не в теме и tailgunner уже, в общем-то, всё за меня сказал.
А, ну прости, дорогой. Программист, программист, конечно же, но всеравно балабол. Тема про устаревание книжек вообще если что. Какие бы подробные и они ни были, они устаревают и очень быстро перестают быть фундаментом для чего либо. Ты, конечно, можешь тут написать, что знание регистров i386 дает тебе все необходимое, чтобы кодить твой системный софт, но как, прости, администратор, хочу тебе сказать, что мы не можем, как в примере выше с Systems Performance (Btendan Gregg), оптимизировать производительность систем без конкретики. Сантехники мы, понимаешь. Вы, программисты, - математики и теоретики, а мы, админы и девопсы, закручиваем гайки. Теперь все нормально, по местам?
А вот и да, ты сам понтанул, мол 10 лет назад было бы интересно, а потом начинаешь задвигать про устаревание. Не, не сходятся файлы у тебя, не переубедишь ты меня.
всё не сходится, если взять твою теорию устаревания, то как оно могло тебе быть интересным 10 лет назад, ведь этого ничего не должно было быть, как-то так. фундаментальность сата когда, кстати, обосновывать будешь?
Сейчас лично мне это (содержимое книги) не интересно не потому, что я 10 лет назад об этом прочитал и такой хожу с этим.) Узнавал со временем, по мере появления. А 10 лет назад я ничего не знал, так что прочел бы и эту книгу с интересом.:)
Ч0рт. Я-то сначала думал, что тема про devops, потом - про ОС.
Какие бы подробные и они ни были, они устаревают и очень быстро перестают быть фундаментом для чего либо
Книги устаревают, конечно. Устаревание книги определяется скоростью развития темы, на которую она написана. Например, учебники по ОС 60-х годов устарвали быстро, а учебники по ОС 90-х годов - медленно.
Фундаментальность - это блочное устройство, а какое оно - sata, fc, hdd или ssd дело реализации. А ценность данной книги заключается в методологиях, а не конкретных технологиях.