Последняя статья уже вызвала немало возмущения, думаю многим эта статья не понравится еще больше, в ней я опишу, каким видят DevOps-инженера заказчики.
Чем больше времени проходит, тем больше я слушаю, что «это обязанность «девопса», запросы к базе хотят, чтобы девупс настроился, догадываюсь, как и с какими зависимостями кодер собирает софт — девупс, евпн+ bgp+ipsec+geo dns +сетевая авторизация по сертификатам - deoops, исправлять архитектурные ошибки и придумывать бескровные варианты - deoops, превратить обычный pg_dump в синхронную репликацию - deoops, быть психоаналитиком CTO/CEO и команды - deoops. Еще одна интересная тенденция — балансировщик нагрузки k8s+на любой чих.
Не так давно мне даже предлагали поставить балансировщик нагрузки на базу, может, средняя нагрузка понизилась бы и диски были бы меньше нагружены.
К8с - это вообще отдельная тема; о связанных с ним мифах можно написать 2-3 статьи.
Все чаще от бизнеса можно услышать, что разработчики и инженеры жадные, что Сбербанк создал мыльный пузырь и что вот-вот произойдет чудо, и мы начнем работать как обычные люди за 60-80к пенсионеру.
В регионах это, конечно, уже есть, и там все было печально, а здесь уже мечтают о всех городах, кроме Москвы.
Еще веселее из того же бизнеса слышать, какие все ленивые, рассказы о том, какие бесполезные работники и что нужно искать способы не планировать работу, архитектуру, думать о будущем, а шлепать некачественный код скорость света, потому что тогда Devoops «масштабирует ее по горизонтали» «Да, у нас в базе 1 запрос, который стоит 15% аппаратной мощности, а 5 запросов означают крах, и что? Горизонтальное масштабирование без выделения ресурсов нас спасёт!!! – Правда не уточняется каким образом.
Особенно если база данных довольно кривая по архитектуре, например дефолтный PostgreSQL или Elasticsearch. Использовать технику по назначению? Нет, это скучно.
Планирование архитектуры, схем данных и их обработка – почему это дорого и медленно.
Но что делать? Выход есть — нанять девупса и обвинить его во всех смертных грехах вашего проекта, не забыв добавить — всё работало ровно до вашего прихода.
Но логи врут, все работало!!! Я все чаще вижу, как довольно интересные и перспективные проекты гибнут даже на начальной стадии просто из-за политических игр.
Я общаюсь с РМ, которому уже полгода мешают продавать продукт, который мог бы принести компании миллиарды рублей в год, но ему постоянно ставят палки в колеса.
Все ищут способы заниматься разработкой, не тратя на нее деньги, а методология DevOps все чаще воспринимается как способ сбросить нерабочий продукт в производство, а косяки прикрыть контейнерами, балансировщиками и затычками, даже если это приводит к низким ценам.
рейтинги и много негатива, главное экономия на разработке.
Как показал опрос в предыдущей статье, у большинства посетителей хабра работодатели пытаются заткнуть несколько дыр одним человеком.
Естественно, не компенсируя этих обязанностей.
Но проблема в том, что в конечном итоге страдает сам бизнес.
Благодаря низкой заработной плате и высокой производительности труда относительно финансовой и технической поддержки бизнес выживает; если бы с таким менеджментом как в СНГ попытались бы вести бизнес в Японии или США, она бы давно обанкротилась.
Многие методологии, пришедшие к нам из развитых стран, были полностью искажены.
Например, Agile, Scrum, DevOps — все 3 методологии требуют для работы существенных изменений в бизнес-процессах, но менеджмент в СНГ к этому не готов, надеются объединить старые привычки и современные методологии, в старых мы на вершине путь, а вы современным и эффективным способом находитесь внизу.
Нет смысла внедрять все 3 методологии снизу, наличие карточек, ежедневных отчетов, планов на 2 недели и релизов по каждой строчке кода не означает, что вы внедрили эти методологии, это означает, что вы ввели дополнительные процессы отчетности это просто поможет найти виноватых и оправдать высшее руководство.
Проекту и людям, которые начинают работать в таких условиях, становится только сложнее реализовать свои планы, потому что количество отчетов вырастает значительно больше, чем если бы их не было.
Сейчас довольно много статей и выступлений странных ИТ-менеджеров, которые уже предлагают платить за результат, почти как раньше за строки кода, отнимая от работы время на обдумывание реализации, учитывая, что это 30-40 минут, а затем просто пишу код. Заодно дайте нам 2-3 недели на обдумывание управленческих решений и подсчет затрат и рисков.
В результате мы все чаще сталкиваемся с тем, что качество продукции неизбежно снижается.
Конечно, это проблема не только в ИТ-отрасли, но и в нашей отрасли она стоит особенно остро, потому что в неудачах потом винят программистов, которые типа «растрачили 180 миллионов рублей».
Я видел уже 4 проекта, которые, как В результате такого процесса не выполнили свои задачи, но потратили 1 млрд рублей и более, но в итоге виновниками стали ленивые ИТ-специалисты и дополнительные отчетные и нормативные процедуры начинают исправлять ситуацию.
Для обеспечения контролирующих функций нанимаются дополнительные менеджеры, снижается фонд оплаты труда ИТ-специалистов.
Количество решений, которые мы принимаем сами, уменьшается, а ответственность и подотчетность возрастают, что приводит к еще большим проблемам.
Вам необходимо четко разграничить границы ответственности и минимизировать их, иначе вы просто станете жертвой в любой политической игре.
В следующей статье я напишу подробнее о том, почему DevOps и Agile, представленные снизу, никогда не будут полезны.
Теги: #Управление проектами #Читальный зал #DevOps #agile #обязанности #права и свободы
-
Твит Стоимостью 1500 Долларов
19 Oct, 24 -
Тапочки Получает Тот, Кто Первым Встал.
19 Oct, 24 -
Google Не Будет Платить Только За Клики
19 Oct, 24
