×Закрыть

Введение в культуру DevOps: о практиках и роли DevOps инженера

Очень часто в вакансиях пишут «DevOps Engineer». Что это за роль? И роль ли это? Что такое вообще DevOps? Какие она в себя включает практики? Почему название позиции DevOps инженер звучит некорректно? Этим вопросам и посвящена статья.

Любая компания, связанная с разработкой или внедрением программного обеспечения, стремится двигаться быстрее и быть как можно гибче. Для этого требуется максимальная вовлеченность разработчиков во все стадии жизненного цикла процесса разработки ПО. Давайте задумаемся, с чего начинается и чем заканчивается этот цикл программного обеспечения. Начинается с планирования — это знают практически все. Но чем он заканчивается? Деплойментом? А куда и как мы деплоимся? Когда заканчивается вовлеченность разработчика в процесс? Стоит ли ему вовлекаться в принципе? И вообще, важно ли то, на какой платформе будет размещаться написанное тобою ПО. Важны ли ресурсы, которые вы под него отведете? Как быстро вы будете обновлять его? Давайте проследим эволюцию процесса.

Как было раньше

Когда только начиналась промышленная разработка программного обеспечения, каждый разработчик был сам себе бизнес-аналитик, архитектор, верстальщик, девелопер, тестировщик, девопс и поддержка 24/7 в одном флаконе. Какие это таило в себе недостатки? Иногда получались достаточно корявые и не понятные для стороннего пользователя продукты. Трудно было представить, что творилось в голове того или иного индивида. И еще один минус — сосредоточение всех сакральных знаний в одной светлой голове, которая могла заболеть, уйти к конкурентам, да и просто уехать отдыхать на Гоа. Однако в этом были и плюсы. Инженер сразу задумывался о полном цикле жизни своего продукта. Тут не было надежды на всемогущего админа, который придет и все порешает за тебя. За любой косяк приходилось выгребать самому и расплата не заставляла себя долго ждать.

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

Почему появилась культура DevOps

Первым фактором стало появление ряда продуктовых контор, в которых вы задумываетесь не только о том, как локально решить ту или иную проблему (проще говоря, тяп-ляп и в продакшен), а о глобальных решениях. Тут не пройдет локальный костыль — и потом пускай с ним разбираются другие. Надо осознавать, что вам дальше придется жить с этим костылем, а поэтому нужно решать что-то на уровне инфраструктуры. Приходится начинать разрабатывать, опираясь на то, где будет размещаться конечный продукт.

Если первый фактор еще может показаться достаточно спорным, то второй — более однозначный. Это широкое развитие облачных сервисов, отказ от хостинга на своих серверах и поддержки своей инфраструктуры как таковой. Выбранная инфраструктура начала определять архитектуру приложения. AWS, Azure, Heroku, DigitalOcean начали делать за вас вашу работу. Теперь не надо без особой потребности придумывать 1001 вариант написания балансера или шардинга — это все доступно из коробки. Это снизило количество велосипедов на квадратный метр, но этот подход, в свою очередь, требует знания инфраструктуры сервисов и адаптации своих продуктов под них.

Кроме того, микросервисная архитектура внесла свою лепту в переосмысление девелоперами инфраструктуры приложения. Теперь недостаточно «наструячить» очередной модуль и залить его в репозиторий, предоставив деплоймент-инженерам угадывать переменные конфига. Нет, теперь надо думать, как это все будет взаимодействовать друг с другом, потому что эта конфигурация может не взлететь даже в вашей песочнице, а отправлять непроверенный код — это как-то уж совсем чересчур.

Платформы начали определять реализацию приложений, поэтому разработчик не может написать хорошее приложение без знаний о платформах. Разработчиков стали привлекать к операционной работе. Появилась культура DevOps. Да-да, именно культура. Почему не роль? — спросите вы. Потому что DevOps-практики, о которых речь пойдет ниже, должны внедряться на уровне компании, а не на уровне отдела или группы. Люди в компании должны знать и о разработке программного обеспечения, и тонкости использования инфраструктуры.

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

Практики DevOps

Теперь давайте поговорим о практиках DevOps. Они достаточно неплохо описаны в книге «DevSecOps The Road to Faster, Better and Stronger Software». Давайте рассмотрим главные из них.

«Automate everything» — автоматизируй все, что можно. Уменьшай количество «ручной» операционной работы. Делаешь, что-то два раза — придумай, как это автоматизировать. Это ускорит все процессы и сведет количество ошибок к минимуму. Работать должен робот, человек должен отдыхать и заниматься мыслительным процессом!

«Configuration management». Docker приходит к нам на помощь в конфигурации, сохранении и менеджменте всего, что нам нужно для успешной работы приложения. Оркестрация контейнеров может осуществляться при помощи таких тулов, как Kubernetes или Docker Swarm.

«Infrastructure as Code». Подразумевается, что подход к конфигурированию приложений должен быть таким же, как и к коду. Если раньше в конфигурации системы через консоль не было ничего зазорного, то сегодня стало уже плохим тоном не использовать для этих целей инструменты автоматизации, такие как Terraform, Chef, Puppet и т. д. Эта практика позволяет оптимизировать ресурсы, а также значительно ускорить время поставки.

«Continuous Deployment». Автоматическое выкатывание готовых фич на рабочее окружение. И если раньше CD системы были игрушкой только для разрабов, то теперь они активно используются для автоматизации накатки изменений в конфигурациях. Эта практика позволяет оптимизировать ресурсы, а также сводит участие человека в процессе поставки к минимуму.

«Application monitoring». Если раньше системы мониторинга представляли из себя различные способы «скирдования» логов, то теперь это мощный инструмент для мониторинга состояния вашего приложения. На анализ логов не надо тратить дни и недели, вы можете настроиться на ту или иную метрику и смотреть за изменениями в режиме реального времени. Мало того, кроме сугубо технических моментов, например количества запросов, перформанса, загрузки CPU, вы с помощью таких систем, как Prometheus, можете собирать и внутренние характеристики приложения, значимые для вашего бизнеса.

Это далеко не все практики, которые составляют культуру DevOps. Однако, как мы можем заметить, они представляют из себя набор методов и инструментов, при использовании которых можно решить проблему быстрой и качественной поставки ПО конечному потребителю, а также как можно быстрее получить от него обратную связь в качестве метрик.

Выводы

DevOps культура — это то, что должно культивироваться на уровне компании. Команды должны не только уметь реализовать фичу, но и организовать процесс тестирования, доставки и обратной связи с конечным потребителем. DevOps практики призваны облегчить жизнь всем — разработчикам, операционистам, бизнесу, потому что именно они являются тонкими ниточками между, казалось бы, на первый взгляд несовместимыми отраслями.


Эта статья — нулевая в цикле материалов по DevOps практикам. В течение месяца я буду писать по одной статье, которая будет давать введение в культуру DevOps. Цикл будет включать такие темы:

  1. Тестирование, все что вы хотели спросить, но стеснялись. Новый взгляд на TDD.
  2. Bash. Знай друга в лицо.
  3. Инфраструктура web-приложения в AWS на примере Node.js.
  4. Docker. Контейнеры. Оркестрация. Docker Swarm. ECS. Kubernetes.
  5. CI. Jenkins. Зачем напрягать роботов, или Когда разработчики глубоко спят.
  6. IaC. Terraform, или Почему не надо менеджить инфраструктуру руками.
  7. Application monitoring. AWS Cloud watch. Prometheus.


О культуре DevOps советую почитать:

LinkedIn

75 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Круг замкнувся: перший допис на цю тему: dou.ua/forums/topic/8681

Опыт успешных западных компаний (english) www.gigamonkeys.com/flowers

„... This is where tearing out those 999 flowers by the roots comes in. Once your engineering org gets to be a certain size the benefits you can obtain by investing in making all your engineers slightly more productive start to swamp the slight gains that one team might get from doing things their own, slightly different way. During the ‚let a thousand flowers bloom’ phase people will have planted all kinds of exotic blossoms, some of which are lovely and even well adapted to their local micro-climate; you need to be able to decide which ones are going to be first class, nurtured members of your garden and which ones are weeds.”

Другими словами, до стандартизации в компании и выделения функций типа security, networks, infrastructure надо еще дорасти. Пока компания небольшая — выгоднее чтобы каждая команда сама выбирала технологии и отвечаала за свои решения

к списку
services.google.com/...​ility-workbook-next18.pdf

The Site Reliability Workbook
Edited by Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara and Stephen Thorne

The Site Reliability Workbook is the hands-on companion to the bestselling Site Reliability Engineering book and uses concrete examples to show how to put SRE principles and practices to work. This book contains practical examples from Google’s experiences and case studies from Google’s Cloud Platform customers. Evernote, The Home Depot, The New York Times, and other companies outline hard-won experiences of what worked for them and what didn’t.
Download for free until August 23, 2018

landing.google.com/sre/book/index.html
Site Reliability Engineering
Edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy

Members of the SRE team explain how their engagement with the entire software lifecycle has enabled Google to build, deploy, monitor, and maintain some of the largest software systems in the world.
Read online for free

В Швеции в IT компаниях сотруднику дают 30 дней отпуска или 6 недель, но в контракте указано что овертаймы не оплачиваются и вы в принципе согласны овертаймить. Это не все конечно компании так делают, но я бы назвал это конкретным примером DevOps культуры. Каждый инженер будет знать что его будут крепить даже ночью и на выходных если будут проблемы с продакшеном. Но в замен он получает прибавку к отпуску.

Получается есть стимул делать все качественно, чтобы в нерабочее время отдыхать, а не "перезагружать сервер =) DevOps way

Получается есть стимул делать все качественно, чтобы в нерабочее время отдыхать, а не «перезагружать сервер =) DevOps way

Бугагашеньки.... А вы вкурсе что делать качественно — это не

DevOps way

Это называется — «делать свою работу качечственно».

Я вообще не понимаю что такое DevOps инженер. Даже википедия пишет что «DevOps (a clipped compound of „development“ and „operations“) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops).»

Особенно возмущает когда админов называют девопсами. Если админ не умеет писать код, то он не может быть DevOps по определению, потому что у него нет «Dev». Если админ умеет писать код, то он не админ, а программист.

В конце концов для программиста не проблема написать скрипт, проанализировать логи или настроить сервер. Если он этого не умеет — какой он нафиг программист?

Девопс — это не профессия, это культура и набор практик. Например в Швеции практически во всех стартапах и компаниях среднего размера нет админов и тестировщиков. Каждый инженер отвечает за свой код и свои решения от начала и до конца. Software Engineer является одновременно dev, ops and qa

Если админ не умеет писать код, то он не может быть DevOps по определению

— Зачем админу писать код ? (Написать скрипт бекапа, проверки сервиса, деплоя — я не считаю разработкой вообще, как и многие коллеги, это — must have для админа).

для программиста не проблема написать скрипт, проанализировать логи или настроить сервер.

Классика современной разработки, после которой проект на 100к посетителей в сутки — сжирает 5к зелени в месяц на счета от AWS.

Швеции практически во всех стартапах и компаниях среднего размера нет админов и тестировщиков. Каждый инженер отвечает за свой код и свои решения от начала и до конца. Software Engineer является одновременно dev, ops and qa

Такой подход подойдет когда в команде есть один два разраба толковых, способных следить и реагировать, но проект если растет и комманда разрастается — такой подход нивелирует всех шаряших разрабов, так как из задача сведется к пилянию инфраструктуры, а не кода.

ІТ — складна штука, в якій неможливо знати все. Але кожен компонент системи може впливати на її надійність та продуктивність. Адміністрування платформи, на якій крутяться сервіси, штука достатньо специфічна, аби її не можна було довіряти самим програмістам. Бо всі свої проблеми вони, здебільшого, вирішують через «chmod -R 777», або копіпасту конфіга, який їм прислав колєга, якому воно допомогло, або просто прибиваючи протухлий інстанс і запускаючи свіжий, або сотню свіжих, якщо час відповіді починає катастрофічно рости.

Ідея девопса — це поставити між девелопером та платформою оператора, який буде робить всі операції в єдиному стилі, не розводячи самодіяльного колгоспу, коли кожен городить, що захоче.

Каждый инженер отвечает за свой код и свои решения от начала и до конца. Software Engineer является одновременно dev, ops and qa

Це зветься «дурна економія грошей». Бо, як вірно сказав нижче колега Трохимчук, зекономивши на зарплатні додаткового члена команди, такі стартапи добряче розкидують гроші на сплату паблік клауд сервісіз. Втім — чого ні. 8-)

Я уважаю ваш опыт и не оспариваю что есть админы и network engineers вплоть до VP positions. DevOps — это другое, на уровне организации, а не одного специалиста

Дякую, я в курсі, що девопс — це культура роботи айтішників в цілому, заснована на Маніфесті. Але тут справа у тому, що у нас в поняття девопс-спеціаліст втягують все що хочеш і дуже часто той самий розробник бачучи, що те, що він розгорнув — не працює як треба, починає робити дурню, точнісінько так само роблять дурню мережеві адміни, коли їх заставляють писати софт, мовляв — у нас всі взаімозамєняємі, так вчить Маніхвест і пророк його девопс😀😀😀. Насправді справа у взаєморозумінні і тісній співпраці.

Шо за Маніфест — я ще не в темі ?

Та ну, воно старе як я 😀😀 розроблене у кінці 90-х і впроваджується з середини нульових
agilemanifesto.org/principles.html
Читать його нада як попи читають молитву — отак його й розуміють більшість хіпстоватих неохвітів 😀😀

Тьху, так це я знаю :) Сподівався що може вже якийсь Девопсо Маніфесто, або СРЕ Манівесто... :)

Наша компания как-то проскочила DevOps хайп и сразу перешла к Service Ownership. Отличная модель, как мне кажется: каждая команда пилит какой-то сервис от плана до сапорта, более крупные организации собирают эти отдельные сервиса в системы (бывает, что это даже работает).

Есть группы которые делают что-то в продуктах, а есть те, кто что-то делает в инфраструктуре. Но все-равно идея одна: потребители сервиса должны понимать как им пользоваться из документации, все взаимодействие через API, а команда сидит на пейджере и следит чтобы все работало.

Сервисом может быть и база данных, и настройтика роутера в стойке, CI/CD, github всех форм и размеров и т.д. и т.п.

Я бы не согласился, что вы проскочили, скорее зашли с паралельного пути. В моей компании такая же практика держалась довольно долго, но в какой-то момент фокус бизнеса начал смещаться в новое направление, даже скорее в разных странах — разные потребности для рынка, и тогда эта модель пошатнулась. Команды начали менять состав, реализововать новые сервисы. Начали появляться «заброшенные» сервисы — новосформированные команды больше не могли тратить время на улучшение.
Тогда мы перешли к модели Application Containers (точное название сейчас не назову), например, Search, Web Consumer, Partners, etc. Каждый «контейнер» — это примерно от 10 до 30 компонентов. В таком разделение все еще может быть core team, но также в состав входят инжинеры из других команд, каждая выделяет 10-20% времени на поддержку компонентов в «контейнере».
Такой подход помог нам сломать барьеры между разными командами, и улучшить обмен знаниями и практиками (зоопарк технологий никто не любит, а для менеджера это еще один риск).

Service Ownership — это ITSM, который вообще о другом и появился гораздо раньше методологии DevOps

DevOps продают под соусом: мы сведем вместе dev и ops, переоткроем для себя матричную модель организации и все эти люди будут получать бонусы только если проект в целом успешен. Не говорим про DevOps инженеров, которые что-то непонятное, но умеют Jenkins и Ansible. В общем DevOps — это отличная модель, в определенных условиях. Но она не очень масштабируется: начиная с определенного количества проектов уже тяжело найти столько Ops и начинается обратный откат в централизованной Ops организации.

В случае в Service Ownership модель немного другая: мы не приписываем Ops к каждому проекту, вместо этого группки ops- и infrastructure- инженеров пилят свои сервиса, которые потом используются dev- инженерами для выкатывания и сопровождения своих поделок. Т.е. ops не приходит в проект и не рассказывает как war копировать куда-то, и перестартовывать что-то, а также как зайти на циску и что-то там подшаманить. Вместо этого они делают так, чтобы «даже девелопер» мог зарелизить что-то в продакшин и настроить что нужно и при этом ничего не сломать.

Мне кажется подобная модель может протянуть немного дольше.

DevOps вже давно не модно, тепер всі SRE.

Когда только начиналась промышленная разработка программного обеспечения, каждый разработчик был сам себе бизнес-аналитик, архитектор, верстальщик, девелопер, тестировщик, девопс и поддержка 24/7 в одном флаконе.

плакалЪ

А ещё напрямую с устройствами работали

и каждый настоящий мужик писал себе драйвера сам

Сейчас на внутреннем рынке, ситуация практически не изменилась))

Девопс — це неотенічна личинка сисадміна. Вже здатна виконувати деякі базові функції, але бозна, чи розвинеться у наступну фазу розвитку. Якщо проект можна замісити з контейнерів на кубернетах, притрусить рамою і залить процами — окей. А якщо ні — тоді ой, вмикається алярм «Хайлоад!» і починається перевод стрілок.

Горизонтально скалити в кубернетах не тяжко, аби аплікуха була для того зроблена. Аплукушки не опи пишуть. Ви про такий перевод стрілок говорили?

Щоби зробить аплікуху, придатну для скалингу, потрібен або архітектор з правильним олієм в голові, або SA+DBA, які вгонять розуму розрабам ще в першому триместрі розробки. Бо якщо девопс проекту знає тільки три блатних тулзи для оркестровки (а в девопсів експертиза нечасто виходить за ці межі), то доля проекту дещо передбачувана. Ну, або клепати сотнями yet another магазини/соціалочки, в яких всі граблі вже добре відтоптані. «А от якби в риби була шерсть, то в ній би жили блохи, а блохи...» ©

Не розумію — як привильну апку задизайнити так вам архітектор потрібен, а як апка падає при 100 чуваках онлайн так девопс який налаштував вам ci/cd винний. ОК.

Нема ніякого CI/CD, казки це все дідуся Панаса. Є або нормальний стейджинг з версіонуванням/тестуванням/викаткою в продакшн, або «косо-криво, аби ажильно».

Глупости. Без сисадминских скиллов девопсы не девопсы

Знаю девопсів, які вміють наклепать інстансів в aws/gce, але не вміють помірять іопси, знайти ботлнек і запропонувать солюшн, або принаймні воркераунд. Одразу здіймають галас «Хайлоад! Заливай процами!»

Я тоже знаю таких. Их полно в Индии и Пакистане

Стоп-стоп. Що значить «майбутні» ? Майбутній сисадмін не вийде з людини, яка знає про розгортання середовищ+має личку розробника. тут треба вже знати трохи більше.

Вибачте, не зрозумів, що ви маєте на увазі.

в копилку — лепят в локальной сети паутину vpn-туннелей, просто потому что IP-роутинг для них неоткрытая Америка
это собственно все прямое следствие хайпа

Тобто ви вважаєте, що з сисадмінів не вийде SRE інженер ? А чому ?

Перекваліфікація сисадміна в SRE — це дауншифтинг. Тому що функції SRE — це дрібна підмножина всіх функцій сисадміна. Як і «розгортання середовищ». Для того, щоб «розгортати середовище» — досить тижня тренинга з нуля. Щоб підтримувати це середовище в робочому стані — ще пару місяців інтенсивки. А от щоб створити from the scratch саме це середовище, копії котрого потім девопси будуть бездумно розгортати — тут вже потрібно не один рік колотитись головою об клаву, і розбиратись в осях, софтах, протоколах, конфігах, скриптах етц.

А от щоб створити from the scratch саме це середовище, копії котрого потім девопси будуть бездумно розгортати

На жаль, але це зараз — дуже нішеве і це вже не сисадмін, це вже Virtualisation Engineer/Architect

да, і відносно дауншифтінга — коли їсти хочеться якось не до таких мислів 8-)

Всю мою чвертьсторічну практику це називалося «сисадмін». А як сучасні хіпстори будуть називати сисадмінів — мені байдуже. Свій перший рутовий аккаунт я отримав в 1988 році, і мені за те платили гроші по хозтемі. Я на сьогодні встиг забути більше, ніж більшість девопсів коли-небудь будуть знати. За цей час я бачив стільки хайпу, стільки народжень та загибелей «нових технологій», які, зрештою, були стандартними ще на IBM/360 (включаючи віртуалізацію і контейнери), що перестав зважати на молодіжну тусню. Сисадмін є сисадмін. Все, що не є сисадмін — або оператор, або технік. Низька кваліфікація.

Круто сказав, підтримую.

Я достаю из широких штанин — то что воздействовать может, мой самый красивый rootовый логин, на гордость мужскую похожий :D

и сколько в ровно платят за чвертьсторичну практику? на пивко хватает?) нынешний девопс или сисадмин это прежде всего гибкость и желание идти на встречу разработчикам. а судя по вашему отзыву у вас закостенелые взгляды типа «вы все школота а я еще в совке по хозтеме работал». врядли с вами комфортно работать когда требуется постоянная динамика

Та не так, шоб дуже платили, забугорські клієнти завжди враховують рівненьский коефіцієнт і відповідно занижують рейт. Коли п’ятнадцять центів за годину платять, інколи двадцять п’ять, тільки лохи якісь є, що платять сорок центів, але їх всього два. Але на пиво вистачає, що є, то є.

Що саме вам видається несерйозним? Рівненський коефіцієнт для аутсорса? Чи те, що можна з Рівного працювати віддалено? Чи, може, те, що можна працювати не фулл-тайм і мати більше одного контракта?

вот эти цифры 25 центов в час смущают

Ну ви ж в першому коменті анітрохи не непокоїлися, вважаючи, що в Рівному за роботу платять менше, ніж в Києві? Мені просто не хотілося вас травмувати :) Коефіцієнт? Окей, нате вам коєфіцієнт.

просто допустим при зп в 2000$ в час выходит грубо говоря 10-11 $. это ж как пахать надо чтоб выйти на эти деньги

так похоже что вам открывают факт жизни за киевской окружной.

если бы я сильно хотел я бы сейчас получал зп в рублях за киевской окружной. киллометрах так за 700. поэтому мне и непонятно че сидеть за окружной =)

Вибачте, я декілька разів намагався зрозуміти, що ви маєте на увазі, але не зміг. 700 км від київської окружної — це на північний схід?

я про донецк) к тому что про жизнь за пределами киевской окружной я знаю больше чем кто то думает

Я все одно не зрозумів смислу вашої репліки. «Якби ви хотіли... тому вам незрозуміло» — оце речення позбавлене сенсу. Програміст на імперативних мовах не повинен так мислити/висловлюватись.

че ж вас так парит скока человеку платят за его опыт и где он живет ? Имхо у вас как у большинства фронтов завышенное ЧСВ, приводящее к мысли что вам кто то — что то должен. Хотя по факту программист должен ставить таск админу — что ему нужно и в какой форме, не админ должен думать что вам надо. Админ видя таск, понимая проект уже анализирует на основе своего опыта и знаний как это все лучше оформить, в итоге получается сотрудничество (то что многие называют DevOps сейчас)- а не

гибкость и желание идти на встречу разработчикам

так как в результате хождения на поводу +

гибкость и желание идти на встречу разработчикам

получается дичь (в силу отсутствия знаний у разраотчиков в области сисадмина, а у сисадмина в области разработки). Это я говорю на основе своего опыта работы на разных проектах и системах, когда после такого сотрудничетва приходилось приводить долго и нужно в порядок проекты....

«Все, що не є сисадмін — або оператор, або технік. Низька кваліфікація» мне этой фразы достаточно) а потом начинается — а вам зачем? вам что одного окружения мало? зачем вам миграции? вот нормально работает пользуйтесь, ставьте задачу когда время будет сделаю и блаблабла

а вам зачем? вам что одного окружения мало? зачем вам миграции?

В моем исполнении такие вопросы звучат не просто так в адресс разарбов, потому что уже не один раз было
— Сделай принудительный https для XXX — через двое суток после релиза QA багу находят с редиректом, оказывается react не следовал редиректу и что то сломалось, при этом рараб не вкурсе был что редирект сломает его код, а проерить не хватило ума
— Настрой нам ФТП на сервр с клиентскими сайатми — в итоге «ой бля — я тут правил код на горячую и удалил нечаянно часть скрипта — давай срочно из бекапа вытягивать» — на поврос какого х...я ты так делаешь есть есть git + jenkins идет ответ «извини — я исправлюсь» и это уже не первый раз.
Я могу долго и нудно вспоминать примеры из своей практики с разных проектов — но суть одна, админ если что то настроил и оно работает, хотел бы знать для чего ему нужно сейчас что то изменить, знать что изменения которые у него просят — требуют нужны не потому что кто то прочитал про блокчейн и хотчет его внедрить для вдеения логов. Знать — все ли на 100% уверены что ничего не навернется, так как в 99% случаев у меня не зависимо от уровня разраба заканчивается все тем что мне звонят когда я отдыхаю семьей в отпуске, или на тренеровке или сплю или еду куда то с кипишем что «Дима у нас сломалось — срочно выйди на связь», и из этих 99% — 99% не по моей вине геморой. То что для одного кажется простым — на самом деле когда начинаешь окнуть разраба в его задачу через время он сам понимает что не все так просто и за минутку не наколбасишь.

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

Все значно простіше. Спробую пояснить на аналогії.

У вас поламалась машина. Неробебля. І ви їдете в сервіс.
В першому сервісі Вася з розумним видом дивиться в діагностику і каже: здох генератор. Купи новий, і я поставлю. Він знає послідовність операцій для заміни генератора, і міняє його. Але машина все одно не їде. І Вася розводить руками. Бо Вася — оператор, і знає лише методичку, як міняти вузли та агрегати.

В другому сервісі Коля каже: можливо, ще проблема в котушці запалювання, від генератора струм іде, але лажає котушка. Бо проблема явно десь на цій ділянці, а генератора ми вже виключили. Ви купляєте нову котушку, але заміна все одно нічого не дає. Коля вже більш просунутий майстер, він мислить дещо системно, розглядаючи нескладні зв’язки та взаємодію вузлів та агрегатів. Він технік, хоча вас це мало радує. Машина як не їхала, так і не їде, зате у вас є вже нові генератор та котушка.

І ось в третьому сервісі Петро каже: в моїй практиці таке викликалось масою причин, на будь-якій ділянці мережі. Зважаючи на те, що контурів багато, і ще є від’ємні зворотні зв’язки від датчиків через контролери, треба дивитись не в типовий діагностичний прилад, а брати осцілограф і дивитись сигналу затухання в різних точках ланцюга. І через годину він приносить шматок кабелю, який погризли миші, а затим під пошкоджену ізоляцію затекла вода. І каже: треба просто перетягнути два метри дроту. А заодне бажано помінять оцю хрінь, бо на заводі ставили що подешевше, і воно має MTBF якраз десь в межах віку машини, тобто подальша експлуатація — це лотерея з сумним джекпотом. І ще оце явно ніхто не обслуговував, я його підтягнув та відрегулював. А якщо ви хочете мати повний фєншуй-хентай, то можна оце прикрутить, а тут попустить, бо на заводі викручують, аби двигун пройшов еконорми, але це призводить до важкого режиму експлуатації, а це шкідливо для TCO, тобто, вашої кишені...

Петро знає систему досконально, в дрібницях, включаючи те, які сайд-ефекти можуть виникати від простих неполадок у третьорядних компонентах. Він не просто знає, що генератор і котушка пов’язані між собою, він знає, як вони пов’язані, і що відбувається, коли зв’язок порушується. І так для системи в цілому, для всіх її компонентів.

Петро — це адміністратор системи. Микола — технік. Василь — оператор.

Возможно речь о разных вещах, но по мне это достаточно смелое обобщение, если вернуться назад от автомобильной темы. Есть например программист. Не салага, который выучил нодочку и погнал формошлёпить. А человек, который хорошо умеет и в программирование, и в базы данных, и в линуксы, и в контейнеризацию и вот это вот всё. Зависит конечно от размеров проекта, но в общем и в целом ему не составит труда под проект, который он ведёт, сконфигурировать сервера, настроить на них софт и контейнеризацию, настроить деплой, настроить балансировку и прикрутить внятный мониторинг. Скорее всего у него это займёт больше времени, чем у штатного админа (девопса, SRE и т.п.) и может выйдет менее изящно, но будет нормально. Этот человек — не сисадмин и по вашей градации его не назовёшь техником, потому что он поднял всю систему целиком. У меня конечно нет 30-летнего опыта, но за мою практику большинство разработчиков, с кем приходилось работать рука об руку, умели всё это делать.

«..человек, который хорошо умеет и в программирование, и в базы данных, и в линуксы, и в контейнеризацию и вот это вот всё..»

Не так давно «програмісти» ще кріпили пластикові короба, розтягували виту пару, а подеколи і меблі переносили. «Ну, ви ж програмісти!».

Я нічого не маю проти широкого профілю, але моя практика свідчить, що навіть одночасно в програмування та в бази даних лише одиниці можуть достатньо якісно. Або окуліст, або проктолог, вибачте. Звісно, якщо проект вимагає мінімального технічного рівня, то можна суміщати усе одразу — UI/DB/SA, і ще трошки шити. Але вже в середніх проектах вимоги до адміністрування виходять за межі можливостей адміна локалхоста.

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

смотрите, а теперь добавляем в начало этой цепи одну малюсенькую детальку
вместо абстрактного сервера, возьмем к примеру какой-нибудь из IBM POWER Systems
и все... если у человека нет соответсвующего релевантного опыта — это будет мертвая точка, с которой он уже не сдвинется

за мою практику большинство разработчиков, с кем приходилось работать рука об руку, умели всё это делать.

то есть к примеру, все поголовно имели опыт администрирования с AWS, Docker, K8S, TeamCity, nginx, HAproxy, Zabbix, ...?
а если нужно GCP/baremetal, KVM, mesos, Jenkins, ELK, ...? тоже?
когда ж они программировать то успевали?

I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain.

Перекваліфікація сисадміна в SRE — це дауншифтинг.

Мені би все життя так дауншифтитися:
www.payscale.com/...​ity_Engineer_(SRE)/Salary

тут питання в тому як на меше що — з початку ти сисадмін, тобто людина яка знається багато на чому, а потмі ти SRE — тобто стаєш дуже вузьким інструментом в компанії яка йде шляхом хайп технологій, але не шляхом здорового глузду. Поки я був адмін — заробляв не багато, хоча знаюсь на багатьох технологіях, зараз мене по контракту обізвали сеньором девопсом — клієнт згоден сплачувати більше, але обов’язки зменшились в тому сенсі що я вже не працюю з залізом, мені не потрібно налаштовувати віртуалки, моніторинг заліза та etc, зараз все у хмарі амазону, мені це не подобається, бо як на мене я тупішим став ніж 5 років тому. Але досвід який я отримав за майже 15 років адмінства — на курсах девопсів, сертифікаціях амазона не дають, та цей досвід вже багато разів показав що він потрібен, бо як тут вже писали не всі overhead ситуації можно вирішити додаванням RAM або CPU. Тому я працюю у декількох організаціях та проектах (віддалено) щоб хоч якось тримати рівень...

Так і я аналогічно. Радикально вилизана система практично не потребує уваги, і цілком може обслуговуватись якимось оператором, в задачі якого входить моніторинг системи та перезапуск окремих сервісів, якщо, скажімо, хттпд починає пам’ять жерти без пам’яті, бо в томкет засунули щось О(n^2), або бінд глохне і не відповідає, або мускль валиться в дедлок при певних умовах, яких не розуміє ніхто, починаючи з того, хто ту базу змайстрував. В якийсь час стає нудно і нема ніякого руху. І хоч місце добре натоптане та пригодоване, хочеться все кинуть і податись шукати пригод на своє комсомольське гузно.

Це заміщення сисадмінів сучасними еквівалентами в мене асоціюється з тим, як змінюється ремонт електроніки.

У давні часи, якщо щось в материнській платі, радіоприймачі чи ін. зламалося, йшли до майстра, який добре розбирався в цьому, і він перепаював конденсатор, транзистор чи що там було треба. Ціна деталі була мала, як і його рейт, і майстру треба було багато знати, щоб вміти робити свою роботу.

Зараз переважно замінюють цілу плату, ціна якої ненабагато менша за ціну поламаного пристрою, або радять купити новий пристрій. Рейт майстра вже не такий малий, і майстру не треба роками ходити на радіогурток, а достатньо вміти гуглити та замовляти з Китаю запчастини.

в мене є теж таке враження, але чи то правильно ? Для тих хто гроші не рахує — нормально, для тих хто рахує та стежить за роботою проекта — дуже важливо. Наприклад коли я у банку робив, у нас був відділ чуваків old shool які ремонутвали все і всим. Вони я так думаю є в багатьох великих конторах — здебільшого про них не знають, так само як і про адмінів, бо коли все працює починається — «нашо нам воно ж і так все працює» (остання фраза то старий прикол). Все одно будуть дурні по типу мене яким мало бути «any key» хоч і за великі грощі, все одно тягне до чогось вже антикварного по типу perl :)

Бачив ситуації, коли деякий інструмент не працює і щоб виправити, треба розбиратися у нутрощах цього інструменту.
І бачив, що вирішують такого типу проблеми часто так: міняють інструмент на альтернативний, який працює))) Якщо і це не допомагає, кажуть, що задачу за розумний час неможливо вирішити))) Переважно бізнес від такого не закривається:)

Це ж як на мене і є DevOps підхід, зробити якось щоб працювало, а як його підтримувати — то вже не моє діло. Бізнес насправді може закритись, коли з такою манерою роботи хтось на RDS виносить базу, сервери у іншому ДЦ, та на місясь рахунок за трафік перевищую всі доходи проекту. Звичайно що великий бізнес це проковтне, але не кожен може собі таке дозволити. Це як мій колега вже написав — підхід оператора, та за такий підхід хтось має сплачувати «over head», тому що це DevOps , а не нормальний адмін працює.

Зачем заниматься рерайтингом? (

?
Якщо у Вас є посилання на оригінал — дайте його, якщо немає — то про що цей комент?

Рерайтинг не говорит что данная статья слизана с оригинала. А о том что подобной информации сейчас в открытом доступе более чем. Описать все другими словами не имеет смысла. Лучше уже вебинары записывать и давать людям информацию согласно трендам

Подписаться на комментарии