Прошлая статья уже вызвала много возмущений, думаю эта статья многим ещё больше не понравится, в ней я распишу то, как заказчики видят DevOps инженера.
Чем больше идёт времени, тем больше я слушаю о том, что «это обязанность «девупса», запросы в БД хотят чтобы тюнинговал девупс, догадывался, как и с какими зависимостями собирается у кодера софт – девупс, evpn+bgp+ipsec+geo dns+сетевая авторизация по сертификатам – девупс, исправлять ошибки архитектуры и придумывать бескровные варианты – девупс, превращать обычный pg_dump в синхронную репликацию – девупс, быть психоаналитиком для СТО/CEO и команды – девупс.
Ещё интересная тенденция – это k8s+load balancer на любой чих. Не так давно мне даже предложили поставить load balancer на бд, авось load average понизится и диски меньше нагружены будут…. K8s это вообще отдельная тема, про мифы связанные с ним можно написать 2-3 статьи.
Всё чаще от бизнеса можно услышать – что разработчики и инженеры зажрались, что сбербанк устроил мыльный пузырь, и вот-вот должно случиться чудо, и мы начнём работать как обычный люд за 60-80к у сеньора. В регионах уже, конечно, такое есть, да там всё и было печально, но тут мечтают уже и за все города кроме Москвы.
Ещё веселее от этого же бизнеса слушать, какие все лентяи, рассказы про то, как бесполезны работники, и что нужно искать способы не планировать работу, архитектуру, думать о будущем, а шлёпать некачественный код со скоростью света, ведь потом девупс его «горизонтально масштабирует», да у нас 1 запрос в БД стоит 15% от мощности железа, а 5 запросов — коллапс, ну и что с того? Горизонтальное масштабирование без выделения ресурсов нас спасёт!!! – правда не уточняется каким образом. Особенно, если БД довольно кривая по архитектуре, например дефолтный PostgreSQL либо Elasticsearch.
Использовать технологии по назначению? Нет, это скучно. Планировать архитектуру, схемы данных и их обработку – зачем это дорого и медленно. Но что делать? Решение есть — найми девупса и обвини его во всех смертных грехах твоего проекта, не забывая добавлять – ровно до твоего прихода всё работало. А логи врут, всё работало!!!
Я всё чаще вижу, как достаточно интересные и перспективные проекты умирают, ещё даже на этапе зарождения, просто из-за политических игр. Я общаюсь с РМ, которому уже полгода мешают реализовывать продукт, который может приносить компании миллиарды рублей в год, но ему ставят палки в колёса постоянно. Все ищут способы как сделать разработку без расходов на неё, а DevOps методология всё чаще воспринимается как способ вывалить нерабочий продукт в прод, а косяки замазать контейнерами, балансирами и заглушками, даже если это приводит к низким рейтингам и большому числу негатива, главное — экономия на разработке.
Как показал опрос в предыдущей статье, у большинства посетителей habr работодатели пытаются заткнуть несколько дыр 1 человеком. Естественно, не компенсируя данные обязанности. Но, проблема в том, что страдает в итоге и сам бизнес. За счёт низкой оплаты труда и высокой производительности труда относительно к финансовому и техническому обеспечению, бизнес выживает, если бы с таким управлением, как в СНГ, пытались делать бизнес в Японии или США, он бы давно обанкротился.
Многие методологии пришедшие к нам с развитых стран были исковерканы напрочь. Например Agile, Scrum, DevOps – все 3 методологии требуют для работы существенного изменения бизнес-процессов, но менеджмент в СНГ не готов к этому, он надеется совместить старые привычки и современные методологии, мы вверху по-старому, а вы по-современному и эффективному внизу. Все 3 методологии бессмысленно внедрять снизу, наличие карточек, ежедневных отчётностей, планов на 2 недели и релизов на каждую строчку кода – не означает что вы внедрили эти методологии, это означает, что вы ввели дополнительные процессы по отчётности, которые просто помогают найти виновных и оправдание для вышестоящего менеджмента. Проекту и людям, которые начинают работать в таких условиях, только сложнее реализовывать задуманное, потому что кол-во отчётности растёт существенно больше, чем если бы их не было.
Сейчас довольно много статей и выступлений странных менеджеров от IT которые уже предлагают платить за результаты, почти как раньше за строчки кода, убирая из работы время на обдумывания реализации, считая, что оно минут 30-40, а дальше чисто написание кода. При этом на управленческие решения дайте нам 2-3 недели подумать и рассчитать стоимости и риски…. В результате мы всё чаще сталкиваемся с тем, что качество продуктов неизбежно падает, конечно это проблема не только IT отрасли, но в нашей отрасли она стоит особенно остро, потому что неудачи потом списывают на программистов, которые типа «разбазарили 180 млн рублей», я видел уже 4 проекта, которые в результате такого процесса не выполняют свои задачи, но израсходовали по 1 млрд рублей и более, но виновны в итоге стали ленивые айтишники и начинается её большее кол-во отчётности и регулирующих процедур, для исправления ситуации. Для обеспечения надзорных функций нанимаются дополнительные менеджеры, а ФОТ для IT специалистов сокращается. Кол-во решений, которые мы принимаем сами уменьшается, а ответственность и отчётность растёт, что приводит к ещё большим проблемам.
Вам необходимо чётко проводить линии обязанностей, и их минимизировать, в противном случае – вы просто становитесь жертвой в любой политической игре.
Следующую статью я напишу подробнее о том, почему DevOps и Agile, внедрённые снизу, никогда не принесут пользы.
Чем больше идёт времени, тем больше я слушаю о том, что «это обязанность «девупса», запросы в БД хотят чтобы тюнинговал девупс, догадывался, как и с какими зависимостями собирается у кодера софт – девупс, evpn+bgp+ipsec+geo dns+сетевая авторизация по сертификатам – девупс, исправлять ошибки архитектуры и придумывать бескровные варианты – девупс, превращать обычный pg_dump в синхронную репликацию – девупс, быть психоаналитиком для СТО/CEO и команды – девупс.
Ещё интересная тенденция – это k8s+load balancer на любой чих. Не так давно мне даже предложили поставить load balancer на бд, авось load average понизится и диски меньше нагружены будут…. K8s это вообще отдельная тема, про мифы связанные с ним можно написать 2-3 статьи.
Всё чаще от бизнеса можно услышать – что разработчики и инженеры зажрались, что сбербанк устроил мыльный пузырь, и вот-вот должно случиться чудо, и мы начнём работать как обычный люд за 60-80к у сеньора. В регионах уже, конечно, такое есть, да там всё и было печально, но тут мечтают уже и за все города кроме Москвы.
Ещё веселее от этого же бизнеса слушать, какие все лентяи, рассказы про то, как бесполезны работники, и что нужно искать способы не планировать работу, архитектуру, думать о будущем, а шлёпать некачественный код со скоростью света, ведь потом девупс его «горизонтально масштабирует», да у нас 1 запрос в БД стоит 15% от мощности железа, а 5 запросов — коллапс, ну и что с того? Горизонтальное масштабирование без выделения ресурсов нас спасёт!!! – правда не уточняется каким образом. Особенно, если БД довольно кривая по архитектуре, например дефолтный PostgreSQL либо Elasticsearch.
Использовать технологии по назначению? Нет, это скучно. Планировать архитектуру, схемы данных и их обработку – зачем это дорого и медленно. Но что делать? Решение есть — найми девупса и обвини его во всех смертных грехах твоего проекта, не забывая добавлять – ровно до твоего прихода всё работало. А логи врут, всё работало!!!
Я всё чаще вижу, как достаточно интересные и перспективные проекты умирают, ещё даже на этапе зарождения, просто из-за политических игр. Я общаюсь с РМ, которому уже полгода мешают реализовывать продукт, который может приносить компании миллиарды рублей в год, но ему ставят палки в колёса постоянно. Все ищут способы как сделать разработку без расходов на неё, а DevOps методология всё чаще воспринимается как способ вывалить нерабочий продукт в прод, а косяки замазать контейнерами, балансирами и заглушками, даже если это приводит к низким рейтингам и большому числу негатива, главное — экономия на разработке.
Как показал опрос в предыдущей статье, у большинства посетителей habr работодатели пытаются заткнуть несколько дыр 1 человеком. Естественно, не компенсируя данные обязанности. Но, проблема в том, что страдает в итоге и сам бизнес. За счёт низкой оплаты труда и высокой производительности труда относительно к финансовому и техническому обеспечению, бизнес выживает, если бы с таким управлением, как в СНГ, пытались делать бизнес в Японии или США, он бы давно обанкротился.
Многие методологии пришедшие к нам с развитых стран были исковерканы напрочь. Например Agile, Scrum, DevOps – все 3 методологии требуют для работы существенного изменения бизнес-процессов, но менеджмент в СНГ не готов к этому, он надеется совместить старые привычки и современные методологии, мы вверху по-старому, а вы по-современному и эффективному внизу. Все 3 методологии бессмысленно внедрять снизу, наличие карточек, ежедневных отчётностей, планов на 2 недели и релизов на каждую строчку кода – не означает что вы внедрили эти методологии, это означает, что вы ввели дополнительные процессы по отчётности, которые просто помогают найти виновных и оправдание для вышестоящего менеджмента. Проекту и людям, которые начинают работать в таких условиях, только сложнее реализовывать задуманное, потому что кол-во отчётности растёт существенно больше, чем если бы их не было.
Сейчас довольно много статей и выступлений странных менеджеров от IT которые уже предлагают платить за результаты, почти как раньше за строчки кода, убирая из работы время на обдумывания реализации, считая, что оно минут 30-40, а дальше чисто написание кода. При этом на управленческие решения дайте нам 2-3 недели подумать и рассчитать стоимости и риски…. В результате мы всё чаще сталкиваемся с тем, что качество продуктов неизбежно падает, конечно это проблема не только IT отрасли, но в нашей отрасли она стоит особенно остро, потому что неудачи потом списывают на программистов, которые типа «разбазарили 180 млн рублей», я видел уже 4 проекта, которые в результате такого процесса не выполняют свои задачи, но израсходовали по 1 млрд рублей и более, но виновны в итоге стали ленивые айтишники и начинается её большее кол-во отчётности и регулирующих процедур, для исправления ситуации. Для обеспечения надзорных функций нанимаются дополнительные менеджеры, а ФОТ для IT специалистов сокращается. Кол-во решений, которые мы принимаем сами уменьшается, а ответственность и отчётность растёт, что приводит к ещё большим проблемам.
Вам необходимо чётко проводить линии обязанностей, и их минимизировать, в противном случае – вы просто становитесь жертвой в любой политической игре.
Следующую статью я напишу подробнее о том, почему DevOps и Agile, внедрённые снизу, никогда не принесут пользы.
