Мы как раз не взяли второй доклад Андрея Квапила, а он как раз про это был. Исправимся в следующий раз. Но с Андреем Квапилом можно пообщаться на конференции :)
Коллеги, различалка «DevOps инженер — это про технологии и про менеджмент, а админ — это только про технологии» так себе и не дает ответов на многие вопросы, например а чем/кем управляет DevOps инженер, если он про менеджмент?
Я все же стою на позиции, что DevOps — это область, а в ней есть множество ролей, минимум их шесть:
— инфраструктурный инженер (строит платформу или работает с уже готовой, например инженер по Amazon)
— сервисный инженер (например строит сервис аналитики или балансировки нагрузки)
— разработчик со знанием DevOps подходов и 12-factor app
— инженер по автоматизированному тестированию
— релиз-менеджер (синхронизирует выкатки и бизнес)
— CTO, который умеет этим всем управлять
Выделение DevOps инженера никаких реальных проблем не решает, кроме появления козла отпущения, да и еще запутывает команды, где вышеописанные роли надо явно определять. В итоге получается такое.
Это действительно калька с английского, такая проблема есть, часть концептов нормально сформулирована только на английском и надо переносить на русский, перенос сделан бездумно, буду над этим работать.
Я сам сисадмин ;) тут рассказ был про то, что сисадмины часто залипают в своей роли и становятся бесчеловечными и чтобы не залипать и обновлять свои знания нужна другая организация и роли и процессы и это и есть DevOps.
То, что вы говорите очень верно, но фокус доклада все же был о другом, если у вас есть экспертиза в семплинге, может сделаете доклад на DevOpsConf devopsconf.io/moscow/2018? Пишите мне в личку, если интересно.
Ну вот вы не смотрели видео, книгу не читали, а говорите. В Америке так принято вести дела, что все делают через продажу и обращение к социальной коммуникации. Поэтому невозможно читать их бизнес-книги. Просто сделайте на это скидку и попробуйте разобраться. Вот про что я говорю.
DevOps — это практика и методология производства цифровых продуктов и платформ. Это не человек, не команда и не инструмент. Практика живая и постоянно развивающаяся засчет глобального коммьюнити.
Коллеги, я часто сравниваю свою способность объяснить, что такое DevOps c объяснением человеку из Саудовской Аравии какой смазкой надо смазывать лыжи при -5 для бега на лыжах свободным стилем.
Вы скорее всего не пробовали и судите о DevOps исходя из своего прошлого опыта, а он, конечно, не совсем накладывается на ваш опыт или наоборот полностью накладывается и вам кажется, что ничего нового.
Так происходит практически со всеми дисциплинами, они разработаны ровно настолько, насколько они разработаны. Для разработки нужна коммуникация, нужны статьи, конференции. Кто-то знает больше, кто-то меньше.
Вон есть термин Физика, Физика говорит, что она изучает мир, но ничего о нем не знает. А еще есть люди, которые про торсионные поля пишут и тоже это Физикой называют.
А DevOps это вообще практика, тут надо пробовать и переделывать и так бесконечно. Тоже самое происходит во всех областях жизни — абсолютного знания — нет.
Смысл этих двух инструментов в управлении зависимости кукбуков и повторяемости у разных людей, так что по сути это аналоги. Но отличия безусловно есть. Мы не используем berks потому, что у нас несколько другой подход, мы для разных окружений используем разные chef серверы.
Лицензия требуется только если вы используете VmWare и его плагин к вагранту, больше ничего не лицензируется. Сам вагрант на винде прекрасно работает, есть даже msi инсталяшка. Если хотите запускать windows в качестве гостевой системы, то этот проект github.com/WinRb/vagrant-windows вам пригодится.
Главное, я думаю, правильно настраивать время хранения raw данных в zabbix, хранить 7-14 дней их в базе, все остально агрегированные значения, про это многие забывают и база из-за индексов разрастается и тормозит на запись. Хорошая производительность заббикса вполне достижима.
Это я :) Я занимаюсь эксплуатацией интернет-проектов. Рассказывать буду всякие истории из жизни со смешными аллегориями. Историии поучительные. А в целом мне интересно понять, что вам не понятно, если вы поясните, то я поправлю описание и больше людей смогут понять, что я написал.
Я все же стою на позиции, что DevOps — это область, а в ней есть множество ролей, минимум их шесть:
— инфраструктурный инженер (строит платформу или работает с уже готовой, например инженер по Amazon)
— сервисный инженер (например строит сервис аналитики или балансировки нагрузки)
— разработчик со знанием DevOps подходов и 12-factor app
— инженер по автоматизированному тестированию
— релиз-менеджер (синхронизирует выкатки и бизнес)
— CTO, который умеет этим всем управлять
Выделение DevOps инженера никаких реальных проблем не решает, кроме появления козла отпущения, да и еще запутывает команды, где вышеописанные роли надо явно определять. В итоге получается такое.
А роли и комитеты нужны, чтобы развивать систему, а не просто в хаосе жить.
Коллеги, я часто сравниваю свою способность объяснить, что такое DevOps c объяснением человеку из Саудовской Аравии какой смазкой надо смазывать лыжи при -5 для бега на лыжах свободным стилем.
Вы скорее всего не пробовали и судите о DevOps исходя из своего прошлого опыта, а он, конечно, не совсем накладывается на ваш опыт или наоборот полностью накладывается и вам кажется, что ничего нового.
Если вам действительно важно узнать, что такое DevOps, то рекомендую посмотреть мой доклад www.youtube.com/watch?v=eIV5D1HSmKI и прочитать книгу www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002
В моем докладе вы узнаете зачем нужен DevOps, а из книги вы сможете взять содержание практики.
Вон есть термин Физика, Физика говорит, что она изучает мир, но ничего о нем не знает. А еще есть люди, которые про торсионные поля пишут и тоже это Физикой называют.
А DevOps это вообще практика, тут надо пробовать и переделывать и так бесконечно. Тоже самое происходит во всех областях жизни — абсолютного знания — нет.