Комментарии 100
Хороший пример двунаправленной blame culture.
оно нигде не работает. просто модные тренды. в айти периодически возникает нечто претендующее на "серебряную пулю" с чем все какое то время носятся как с писаной торбой - devops, agile,Nosql, Goland,микросервисы,"продуктовость" и так далее. пули естественно не получается и "нечто" занимают ту скромную нишу где оно худо бедно раотает
devops
На моей практике вполне себе работает, если говорить о таких вещах как IaC, CI/CD.
agile
Тоже работает. Не идеально, но есть проекты, где такие подходы разумнее, чем традиционный waterfall.
Nosql
Работают, разве что следует умерить ожидания и сразу понимать, что скорость и другие качества таких баз достигаются не магией, а жертвами в других областях.
микросервисы
Тоже работают, но, опять таки, требуют рационального и прагматичного подхода i.e. distributed monolith в десятки раз хуже обычного.
Короче говоря, не совсем понял, что вы понимаете под «оно нигде не работает». Некий оттенок хайпа и трендов — да, это я замечал и в целом согласен, но не считаю это inherent проблемой описанных подходов. Более того, удачное их применение выигрывает по сравнению с альтернативами.
Работает-то всё из этого, просто в каждом из этих вещей есть "..., если применять с мозгами там, где оно требуется". А проблема всех новшеств в айти - слишком много хайпа и подачи, будто именно это новое решение есть панацея всей разработки.
Осталось только осознать, что DevOps это про культуру взаимодействия Dev, Ops, и прочих; для достижения общих целей. А не эти ваши иаки и cicd, которые задолго до DevOps существовали
Лет много назад мы с товарищем собирали митапы архитекторов - благо компания, где я тогда работал, с удовольствием предоставляла под это помещение и плюшки с кофе. На один из них пришел мужик в возрасте, сел недалеко от сцены и смеялся практически всю первую часть дискуссии. В перерыве я его нашел и спросил о причине веселья. Тот ответил что те же самые проблемы, над которыми бьются лучшие умы IT - в телекоме решили еще в 70х. Например - зачем нужна "очередь запросов", если запросы гораздо логичнее класть в стек. Признаться, у меня не нашлось хорошего ответа.
По поводу Аджайла и прочего NOSQL - это работает только там, где не делают из него религию.
зачем нужна "очередь запросов", если запросы гораздо логичнее класть в стек
А вот тут возникают вопросы что он подразумевает под "стеком", где он хранится и что будет если выключат электричество.. Опять же, если под "очередью" подразумевается некая структура на сервере приложений - это одно, если в самой БД сделана некая "табличка" - это другое, а если у вас есть какой-нибудь менеджер очередей типа IBM MQ поверх которого работает брокер сообщений, который рулит запросами от кучи клиентов - то это совсем третье...
Речь шла об архитектуре - вам приходят запросы, вы их где-то сохраняете и по мере сил обрабатываете. Почему в принципе следующий запрос на обработку должен браться из "хвоста" очереди, а не из ее "головы", как все обычно делают? А как именно очередь имплементирована - здесь значения не имеет, есть какой-то интерфейс и все.
Так многое зависит от задачи, я тоже не понял, чем этот мужик так вас зацепил. Очередь часто используется потому, что в событийных архитектурах важно обрабатывать события в порядке поступления.
Условно говоря, если вы отправляете два смс подряд, то хотелось бы, чтобы то, что вы отправили раньше, раньше и пришло.
SMSC совсем не гарантирует передачу SMS в оригинальной последовательности - и если, например, какое-то длинное OTA сообщение делится на части - правильная их "сборка" обратно это проблема телефона (в формате, разумеется, есть поля "номера части" и "всего частей").
TCP-пакеты в разветвленной IP сети тоже приходят (если приходят) "как попало"...
Насчет мужика - это называется Design for Failure (хотя тогда еще таких слов не знали). На пиках нагрузки вы можете не успевать обрабатывать все запросы до того у клиента закончится таймаут и он пошлет тот же запрос еще раз (нажмет "refresh" в браузере). Очень возможна ситуация, когда вы 100% заняты обработкой запросов, ответов на которые уже никто не ждет - а клиенты шлют все новые и новые, не получая ответа. Поэтому, лучше брать запросы из "хвоста" очереди - тогда получившие ответ перестанут вас "DDoS-ить".
По поводу "событийных архитектур" - обработка в порядке поступления это далеко не самая лучшая идея. Если бы, например, банковские и платежные системы так работали - все бы было довольно печально.
Мы с вами на разных уровнях абстракции. Я имел ввиду что-то ближе к современным месенджерам вроде WhatsApp'а, где сообщения показываются в порядке получения.
Если ваш сервер не успевает обрабатывать запросы, то стек это явно не решение проблемы. Вы точно также будете не успевать обрабатывать сообщения из стека. Проблема с сообщениями, на которые никто уже не ждёт ответа решается временем жизни таких сообщений.
Вы поправьте меня, но ваш тезис выглядит со стороны как 'везде, где используются очереди, можно использовать стек, и стек гораздо лучше'.
Сообщения "показываются" != "приходят". Ничто не мешает включить время в формат сообщений и расставлять их в нужном порядке на клиенте (я более чем уверен, что так и делается).
У траффика есть пики и провалы - резервировать мощность выше пиков может быть очень дорого.
Ничто не мешает включить время в формат сообщений и расставлять их в нужном порядке на клиенте
То есть, пришло мне десяток сообщений с временной меткой около "09:50", я их прочитал и даже ответить успел, а тут до меня только дошло (по разным причинам) сообщение с меткой "09:49" и встало выше того десятка как непрочитанное.
Сообщения "показываются" != "приходят". Ничто не мешает включить время в формат сообщений и расставлять их в нужном порядке на клиенте (я более чем уверен, что так и делается).
Ну то есть без какого-то осмысленного технического обоснования заменили очередь на стек, а теперь всем остальным нужно лепить костыли, чтобы это заработало. Отличный план.
Чтобы порядок сохранялся? Если там запрос на создание документа, потом на его модификацию, например, если очередь то они так и обработабтся, а если стек, то надо сначала модифицировать потом создать. А как?
Смотрите шире - в масштабах всей системы, а не отдельной сессии. Допустим, случился пик нагрузки - и запросы стали задерживаться какое-то время в очереди (если нагрузка мала - то алгоритм работы с очередью не имеет значения, она будет пуста). Ваш клиент пошлет "запрос на создание документа", у него истечет таймаут и что он сделает - пошлет еще один.
В результате - вы у себя видите что все ОК и запросы обрабатываются в максимально возможном количестве - а с точки зрения клиентов, сервис "в дауне".
Поэтому, даже если это не совсем честно по отношению к "ветеранам очереди" - лучше сразу удовлетворить самых "свежих" клиентов и постепенно "разгрести" оставшихся.
Если смотреть шире, то и для очереди и для стека есть места, где они оптимальны. Спор по сути о том, что лучше вилка или ложка
Изначальный посыл - вы едите вилкой хехе, а мы давно едим ложкой. Вот, возьмем, например, суп.
Метарассуждение:
Обычно, когда все делают X, потом приходит дедок и говорит "Вы дураки и не лечитесь, а надо делать Y" вариантов несколько:
Дедок самый умный, а весь остальной мир - тупые. Это самый маловероятный вариант. Даже Эйнштейн не отменил Ньютона - релятивистскую поправку при сложении скоростей почти никто не использует
Дедок занимается какой-то узкой нишей и него оправдано Y. Понять, что у других по другому, он не осиливает. Иногда эта узкая ниша потихоньку разрастается и теснит другие (ну или быстро), но обычно для X всегда остается место
Дедок - Кулибин, он придумал Y и он захвачен идеей. Смотрите! Это Я! Я! приудумал! Обычно он не удосуживается изучением существующих способов сделать то же самое и закрывает глаза на какие-то аспекты реальности (а то получится, что идея не такая уж иновая и уже кем-то опробована, но не подошла).
и для очереди и для стека есть места, где они оптимальны
Разумеется. Пример был о том, что "оптимальность" может быть довольно неочевидной, и ее уже нашли много лет назад.
До телекомов эти же проблемы решали в эпоху индустриализации, но с реальными товарами, железом, станками и углём, а не с абстрактными цифроывми данными.
>Goland
А что не так с этой замечательной IDE от JetBrains?
Она не умеет дебагать сервисы в K8s так, как это можно делать в VSCode с помощью Bridge to Kubernetes. Приходится извращаться — запускать VSCode, там создавать туннель из кластера в локальное окружение, потом переходить в Goland и там уже дебагать. Обидно, что в бесплатной IDE можно комфортнее работать, чем в платной.
В Goland можно настроить запуск произвольной команды перед стартом дебага, а именно запуск kubectl port forward, да и всё. Если не нравится cli, попробуйте Lens. Через него очень удобно прокидывать порты, не залезая в консоль.
А ещё есть telepresence, или если эти варианты не угодили.
port forward не подходит — мне нужно не в k8s дебагать сервис, а запускать его локально и перенаправлять трафик из кластера на мой localhost.
Дебагать в кластере с помощью dlv я пробовал, работает, но пересборка и деплой нового бинарника занимают непозволительно долгое время. Кроме того требуются манипуляции с настройками деплоя, т.к. по умолчанию инстансов пода в кластере может быть несколько, и никогда не знаешь, куда прилетит коннект (я уж не говорю о том, что для удаленного деплоя мне нужно наши деплой скрипты патчить).
Телепрезенс мог бы быть альтернативой, но он у меня не завёлся. Во-первых, трафик перенаправлялся на локальный инстанс только непродолжительное время, а потом переставал. Во-вторых, сам телепрезенс периодически не мог определить, что он установлен в кластере, и даже не мог удалить сам себя. В общем, штука крайне ненадежная оказалась. Кроме того, его манипуляции с кластером гораздо сложнее, чем то, что делает Bridge to Kubernetes.
Но так или иначе, использовать ли VSCode + Bridge или Telepresence — не так важно, важно, что Goland не поддерживает фичу даже с плагинами, чтобы не нужно было запускать стороннее приложение. И, похоже, что это даже не стоит в приоритетах разработчика. У разработчиков бриджа есть в Roadmap поддержка Intellij, но когда это случится — неизвестно. В худшем случае никогда ;)
Со стороны GoLand также тикет на эту проблему: GO-12338.
Язык Go имелось ввиду
Устал отговаривать бездумно впихивать все подряд в докер.
"Нет! Контейнеры - это модно!" отвечают мне.
Скорее я человек с 2 по русскому, которому ставили 3, чтобы не парится))))
Статья — это результат оформившегося желания рассказать о чём-то миру. Так уж исторически сложилось, что текстовый формат, в отличие от аудиовизуального (подкасты, видеоролики), подразумевает структурированность и соответствие нормам языка, на котором написан текст — в противном случае его просто-напросто неприятно читать, примерно как и слушать бесконечные «эмммм», «вот», «как бы» и другие слова-паразиты.
Не то чтобы я вас в чём-то обвинял (сам не без греха), просто в моём мире «свидетелей рунета первой волны» — это демонстрация неуважения к читателям.
Скорее я человек с 2 по русскому, которому ставили 3, чтобы не парится))))
Ну хоть здесь не менеджеры виноваты)
Скорее по литературе. В след. раз, пожалуйста, напишите где-нибудь план статьи - сразу лучше будет, на порядок.
Начал читать, понимаю что похоже на хрыча. И надо же, это хрыч.
Заголовок к статье отношения не имеет, а этот плач уже выбился за пределы телеграм чатов и достиг хабра.
1) это проблема не только DevOps / Agile, это общая проблема бизнеса. Кратко: с менеджерами всё плохо.
Хороших менеджеров, которые умеют разруливать организационные проблемы -- очень мало, ещё меньше, чем хороших программистов. И у программистов хотя бы есть какое-то решение по уровням jun / mid / sr, а у менеджеров нет. Поэтому хорошие с средними и начинающими сидят на одних должностях и зарплатах, пока не уйдут на другие должности.
Плюс в России лет 20 подряд всеми вузами страны выпускали толпы совершенно бестолковых менеджеров, которые не умели вообще ничего - на уровне ПТУшников. Это ещё сильнее усугубляет общую проблему.
В общем, за всё время работы из тысячи менеджеров, что я видел, хорошими реально были 2-3. Остальные вообще не думали, потому что не умели. И созданные ими проблемы расхлёбывали специалисты всех уровней.
2) В России есть особая культура целования задницы клиента. Я слышал, что она развита и в некоторых других странах, от Франции до Японии, но сам не сталкивался, поэтому мне сложно сравнивать. А в России если денежный клиент капризничает - вся фирма должна лечь под него и облизывать, пока тот не успокоится.
Потому что менеджер, прослойка между клиентом и исполнителем, прогибается во все удобные позы, лишь бы не сказать клиенту "нет". И вслед за ним эти движения повторяет вся фирма. Если клиент внутренний, например, мелкий босс, то всё точно так же -- дурное настроение босса или его дебильные решения расхлёбывают все, потому что никогда промежуточные звенья не будут ему перечить. Все трясутся за свои рабочие места, премии, кабинеты и общую благосклонность.
А боссы, часто очень неглупые люди, привыкают к тому, что у них не просто компания, а "5-звёздочное обслуживание", и прощают менеджерам из постоянные косяки. Зато ими так приятно руководить! Сотни раз сталкивался с такими ситуациями, и всего несколько раз слышал, чтобы кто-то набирался смелости возражать Главному. Даже если это контора из 30 человек, и босс - большая лягушка в мелкой лужице..
Я слышал, что она развита и в некоторых других странах, от Франции до Японии
"Не только лишь всех", да. Понимаете, людям тяжело слать начальника с гениальными идеями на 3 буквы, если от него напрямую зависит зарплата. С этим пытаются бороться, типа зарплату назначает начальник начальника, как относительно независимый человек. Но результат всё равно ещё тот.
А в России если денежный клиент капризничает - вся фирма должна лечь под него и облизывать, пока тот не успокоится.
Было такое, длилось пока клиент не покинул рынок в результате банкротства. Облизывание дошло до того, что некоторые фичи пилились в тесном сотрудничестве с исполнителями клиента, без должного документирования и т.д., из рук в руки так сказать. Долгие годы после банкротства этого клиента ещё всплывали вопросы о существовании фич в проекте, смысл которых никто не мог объяснить толком. Очень забавно выглядит контора не способная ответить уже новым клиентам, на вопросы о функционале в своем же продукте, на которые те случайно наткнулись.
Дополню от лица менеджера историей из жизни - разместил своё резюме в соц. сетях, пришли бывшие коллеги из одной крупной еком компании, где я работал 3 года назад с плачем Ярославны, что всё плохо и проспали все полимеры. При этом коллеги, ведущие разрабы, архитекторы и консультанты. Возвращайся мальчик с нами, будешь нашим королём! (с).
Удивился, меня никогда не хантили архитекторы и разработчики, ладно интересно, чего там сейчас и как. Выслал резюме, сказал сколько хочу сейчас денег и предупредил, что сомневаюсь, что они столько предложат, т.к. 3 года назад ушёл потому что компания перестала быть в рынке по зарплатам.
Через 2 дня позвонил лид менеджеров и уже не из ИТ. Как и предполагалось, предложили в 2.5 раза ниже рынка, на проекты и продукты, которые находятся в перманентном огне и говне (за год на одном из них сменилось 8 менеджеров).
Весело посмеялся, пожелал удачи и хорошего настроения и для понимания, рассказал, как на такой же продукт нанимал человека на ЗП в 2 раза больше с функционалом в 2 раза меньше, но реальной экспертизой.
Дискутируя с заголовком, а не с содержанием, замечу, что и девопс и гибкие методологии разработки работают - но только если к ним прийти эволюционным путем. Нельзя просто взять за шиворот команду, работающую по лекалам прошлого века, и закинуть ее в светлое будущее. Так же как нельзя цивилизацию из феодализма зашвырнуть в коммунизм, где все в кайф.
Имел честь работать в стартапе, сформированный людьми, бежавшими от сберджайл-трансформации. Все практики у нас прекрасно работали.
Это один из способов борьбы с недоверием. В 90-е доверие вообще было как мишень для приколов в самом мягком случае.
С обеих сторон очевидно. Менеджеры не доверяют, потому что сами осознать предлагаемые решения неспособны, а команды (тут скорее о лидах речь) не слишком напрягаются в попытках свои решения объяснить, показать не просто отдельный случай, а хотя бы инженерный план достижения цели . Команды не доверяют, потому что могут прийти и сказать "сворачивайте ваши Иксперименты и развитие и делайте кондово и бегом".
А тут еще разработка, которая помимо производства софта еще и конструирование содержит и элементы НИОКР. И получается, что на цикл ОКР-конструирование-производство менеджеры 2-3 слоев и команды натягивают гибкие процессы. Сложность растет быстрее компетенций и тех и других. Пока проект небольшой, разбираются. В энтерпрайзе под это дело уже весь управленческий состав до тим-лидов включительно нужно очень серьезно готовить. Одних цели формулировать и управлять их изменениями не "а сегодня начинам жить по новому", других выстраивать процессы, третьих создавать и изменять решения достижения этих целей. Взаимное доверие только за счет взаимной уверенности в профессионализме может появиться. И один "случайно залетевший в систему" менеджер его легко может порушить. А это частый случай, вот и тянутся все к модели нулевого доверия.
Ждем следующие части!
Согласен с автором статьи. Но, мне повезло у нас технический директор может сам написать любому рядовому сотруднику, при необходимости. В этом плане, это очень здорово! :)
ИМХО, очень наивно считать, что менеджмент глуп, некомпетентен или способен понять важность чего-то. Средний руководитель прекрасно понимает цели DevOps, DevSecOps, Agile, Scrum, CI/CD и кучи других вещей. И часто гораздо лучше знает, зачем это нужно или не нужно в компании. Но при этом он прекрасно понимает, что из этого принесете ему пользу или не принесет.
Зачем внедрять DevOps, если ты собираешься через полгода уходить из компании? Лучше пусть собирают руками, зато релизы предсказуемые (а так они станут предсказуемыми через год, а тогда уже менеджера тут не будет).
Заменил Agile на какую-то странную систему, когда сначала формулируется набор задач на два месяца, а потом каждую неделю готовятся отчеты по тому, что сделано? И не важно, что через год это все развалится, зато сейчас есть хорошие отчеты и графики. Если ты уходишь через полгода, то план абсолютно рабочий.
Сваливать все на сотрудников абсолютно логично, менеджер не идиот, чтобы брать вину на себя. Много ли разработчиков не в маркетинговых статьях (вида "я совершил ошибку, мы потеряли 1000 миллиадров, но меня не уволили, смотрите, как важно учиться") выходили и говорили "Да я забил на работу, из-за меня упали сервисы, утекли данные людей, кого-то угнетают"? Не очень много. А почему менеджер должен так делать?
Тупых менеджеров крайне мало, даже если они так выглядят. И попытки рассказать им, зачему нужен DevOps, обречены на провал, так как менеджеры это уже знают прекрасно, он им просто не выгоден. Поэтому основная задача - это показать менеджементу, почему какая-то инновация полезна именно им. Или почему ее отсутствие приведет к проблемам именно у менеджмента, которые простым увольнением не убрать.
А DevOps'ам этот самый девопс (точнее кубер и сиай) нужны примерно для тех же целей - внедрил, вроде что-то работает, пока разбираются - меняешь работу. Видимо для win-win нужно просто договорится с менеджером.
а про глупость и не сказано, сказано, что всех интересует только имитация деятельности, надо принять как можно больше решений, ведь их эффект будет только среди челяди, а верхи и дальше будут жить спокойно
Если одним абзацем для Лиги Лени:
Не работает там, где менеджмент на всех уровнях в этом не заинтересован/не понимает.
https://youtu.be/_Z_VnOaIYAc Х.Х и в продакшн! Немного с другой стороны про аджайл и скрамп
Бессвязный кому души. Не знаю, как у автора с девопсом - но с русским точно плохо. Обидели инженера в кровавом энтерпрайзе? Не дали поставить любимую версию хадупа? Заставили на директора посмотреть? Вот сволочи.
Наверное, в той компании действительно был плохой менеджмент. Он вообще часто плохой. Но с плохим менеджментом через задницу работает не только девопс, а вообще все толковые методики работают через задницу.
Но свою обиду на одну компанию выдавать за экспертную оценку индустрии - не надо. Даже если в индустрии действительно такая ситуация, это некорректно и нечестно. Если хотите пожаловаться - пишите с названием организации. И на профильный сайт жалоб на работодателя, Хабр вроде бы не жалобная книга.
Я технарь, но не IT, а строитель. За годы работы понял следующее:
В структуре управления то что говорят и то что делают это две разные вещи. Потому что управляющий или тот кто может влиять преследует свои глобальные/местечковые цели и интересы. Внедрение новой структуры управления это перераспределение ответственности, бюджета и прав. Собственно этот конфликт интересов и обеспечивает неработу всего такого.
Из экономики известно чем глубже уровень разделения труда, чем дальше цепочка от идеи до модели, проданной потребителю - тем выше риски, которые распределяются внутри этой цепочки. Применительно к структуре управления, условно раньше ты мог придти зеленым рабочим на завод/предприятие, пройдти по горизонтальным лестницам и затем, в случае удачной карьеры, ты понимал как и что работае, тебе не нужно десятки согласований или их будет требоваться на порядок меньше.
Сегодня управленец это такой же винтик как и инженер, но с правом решать. Стараясь минимизировать риски в деятельность втягивается уйма народа, что бы размыть ответственность.
У молодого поколения управленцев и менеджеров (условно возраст до 40-45лет) есть огромный соблазн и желание управлять по статистическим данным (в т.ч. из-за влияния проблем в п.2.) Для этого увеличивается отчетность и кол-во показателей. Иногда это работает, но чаще нет. Но это же созвучно сути бюрократического аппарата любой фирмы/гос-ва. Т.е. нужны технологии и инструкции, по которым будут работать люди. Увеличение отчетности приводит к побочке: если раньше специалист хоть что-то на своем уровне решал сам, за счет рабочего времени или даже нерабочего, в рамках своих компетенций, то теперь специалист это больше или меньше оператор данных, которые он собирает, структурирует и передает дальше. Решают другие! А управленческие специалисты, как правило, теперь не имеют знаний и опыта в рамках компетенций технических специалистов, в результате они либо не понимают части проблем, либо даже их не видят. Усугубляется это еще и трудовой миграцией между отраслями, когда условный выпускник педа/эконома идет на стройку, а технарь в бухгалтерию... Тут кто как устроился и кому как повезло или "повезло"
Человеческий фактор.
Больше всех в колхозе работала лошадь. Но председателем она так и не стала.
Тех кто вывозит технические процессы с управленческой точки зрения повышать глупо, т.к. на их место придут другие, кто перестанут вывозить. А вот тех кто решает управленческие проблемы могут и повысить. Второй вопрос в том как отпиарить решение проблемы, т.к. люди существа эмоциональные и могут заморачиваться с одной стороны над тем что и яйца выединого не стоит, а с другой не считать проблему проблемой. В итоге субъективизм чистой воды на всех этажах управленческой вертикали + связанные личным интересами и союзами группировки и отдельные люди. Ищи кому выгодно. Если руководитель тебя хвалит за решение задач это может так же означать, что наверх он докладывает что сделал это сам или именно его идея или воля в нужный момент оказалась решающей. Даже если это руководитель из другого отдела.
Если не секрет, как вас занесло в обсуждение девопсов?
В детстве мечтал стать программистом, осилил Spectrum Basic, QBasic 4.5, Borland Pascal 7.0. Сейчас пишу формы под себя с применением VBA. Пишу и комментирую для себя интересное на Хабрахабре. На стройке работал мастером, мастером в эксплуатации котелен, сейчас я сметчик, но руководство переодически бросает аварийно латать дыры с документацией ПТО по объектам время от времени, приходится ситуативно руководить. Поэтому все что связано с управлением/руководством интересно.
Так у Вас все данные чтобы в программисты пойти. Не пробовали?
Не пробовал, потому что с одной стороны меня программистом никто не ждет, мне скоро 40лет, стабильно платят з/п чуть выше рынка, в своей сфере есть опыт и даже широкая известность в узких кругах. =) С другой стороны з/п не дотягивает даже до джунов в МСК.
Планирую как хобби что-то освоить навроде C с чем-нибудь, что бы делать модули под Excel и библиотеки закрытые для документооборота, но это хобби, впрочем в этом году со вводом обязательного электронного документаоборота в строительстве все это может пойдти по одному известному пути - дорогой добра, т.к. не смотря на удобства у меня нет денег и времени конкурировать с программерами на з/п и софтом от компаний - лидеров рынка типа 1С, Арос, Алтиус и т.п. в части специализированного софта.
Тех кто вывозит технические процессы с управленческой точки зрения повышать глупо, т.к. на их место придут другие, кто перестанут вывозить. А вот тех кто решает управленческие проблемы могут и повысить.
Когда «неповышение» сопровождается регулярным и достаточным увеличением зарплаты и прочими ништяками — при условии, что появляются интересные задачки, лично мне, как технарю, большего и желать не нужно, гори оно синим пламенем, это повышение.
Куда мне, как сисадмину, «повышаться» по вертикали? В руководителя отдела эксплуатации? Пробовали, знаем — почти везде это уход от работы головой и руками в сторону работы ртом.
Куда мне, как сисадмину, «повышаться» по вертикали? В руководителя отдела эксплуатации? Пробовали, знаем — почти везде это уход от работы головой и руками в сторону работы ртом.
Я не оспариваю Ваш выбор, вполне может быть что лично для Вас так оно и лучше. Но когда руководители люди без бэкгрануда технического или хотя бы не прошедшие по горизонтали по нескольким смежным рабочим/техническим должностям, что бы знать как оно устроено изнутри, то получаем такие вот вещи как в этой статье, потому что или не хватает опыта/кругозора, или знаний что бы корректно оценить и просчитать последствия, подменяя такие знания внешним/внутренним аудитом. Бюрократия не только полезна, но и вредна.
"За бугром" также, Россия в этом вопросе не уникальна.
Везде так. Довелось мне как то быть начальником, и даже пару раз большим. Постоянно требуют оптимизацию ресурсов, ВСЕХ. Пережил и "бережливое производство" и даже внедрение Тойоты %) Приходит новый админдир или эфективный менеджер и начинаеться, то бишь каждый полгода-год перетрахивание всего. А по факту страдает производство, теряються довольно ценные и редкие кадры. Но в странах постсовка везде так. Тойота хороша, но.... Для Японии, у нас же руководство считает что этот подход онли для рабочих и прочей челяди)
Всем добра, особенно на работе!
Уже написали, что это не только в России не работает.
Я только хотел напомнить о великолепном сайте и манифесте Programming, Motherfucker, который создан далеко не в России.
А автору я бы рекомендовал думать о тенденциях и причинах, а не о место действия. Когда agile не работает, это не потому что в России, а потому что agile. Кстати, когда agile работает (а он иногда и работает) это тоже не из за России/Нероссии а из за других причин.
Типичный плач Ярославны от человека с внешним локусом контроля. Автор, работай над своим окружением. Воспитывай своих менеджеров, а если не воспитываются — ищи других. Если ты хороший спец — тебе будут рады в любой конторе на рынке, а если нет — то иди работай над собой сначала.
Agile - интересен для проектов с неизвестным сроком и стоимостью, waterfall - наоборот.
Когда строим серийную многоэтажку в спальном районе или обслуживаем конвейер тойоты.шушары - применяем водопад, потому что известны ресурсы, сметы, снипы, ставки, нормы... Все это ясно отражается на диаграмме Ганта и стендах бережливых производств.
Напротив, разрабатывая стартап Uber, применяем гибкий подход, так как точное планирование может потребовать ресурсов больших чем сама разработка (например времени за которое конкуренты сделают проект быстрее и снимут первую пену).
Задача управленца состоит в декомпозиции проекта на ряд ясных задач, возникающих так же и в процессе работы опираясь на бэклог, а не только начальные и случайные хотелки верхов.
Идея создания MVP, как реально минимально-работающей системы, позволяет оценить эффективность проекта с последующим наращиванием функционала и масштабированием.
DevOps позволяет реализовать итерационное и непрерывное управление такой разработкой.
Вопрос культуры применения agile и devops будет стоять до тех пор, пока не появится мотивация низов брать задачи. А это подразумевает сдельную оплату труда и отсутствие социальных гарантий.
Минусуют так понимаю те программисты и эффективные манагеры, что пригрелись на окладе в 100500 и приспособились удовлетворять вышестоящий уровень по принципу "к пуговицам претензии есть?".
Экономика ожидаемо уперлась в кризис перепроизводства и комфортные условия труда ведут к империализму и последующему краху. Для того что бы этого избежать была разработана гибкая методология, особенно актуальная стартапам и инновациям, в противовес жесткому планированию.
Глобальная сеть позволила работать над продуктом совместно и инструментарий DevOps позволяет управлять этим процессом точно и непрерывно.
Другое дело что пихать модные тенденции под любым соусом, регулируя процесс по прежнему кнутом и пряником - неэффективно. И важно понимать что стартап или инновация - это риск. Так почему команда не принимает его и просит оклад и СП?
За что минуса? Хоть намекните?
Потому что это подразумивает не сдельную оплату труда, а процент от прибыли, во вторых, внизу задачи и так берут, только вот задачи должны быть грамотно поставлены, а этого делать не умеют, потому что идёт гонка волевых решений и кто их больше примет.
Вы же предлагаете ещё больше ответственности внизу, и вообще убрать сверху.
Сдельная оплата или процент прибыли, равно как оклад или опцион - по сути это договор "заказчик-исполнитель" в той или иной нотации или трактовке. Какие то условия прописываются письменно, другие принимаются негласно.
Полностью согласен с важностью грамотной постановки задач говоря об этом:
Задача управленца состоит в декомпозиции проекта на ряд ясных задач, возникающих так же и в процессе работы опираясь на бэклог, а не только начальные и случайные хотелки верхов
Ну вот мне не нравится риторика вида "Минусуют так понимаю те программисты и эффективные манагеры, что пригрелись [...]", я за такое всегда ставлю минусы не читая дальше.
Проблема такая есть не только в Российских компаниях, но и в международных, а ещё есть российские и международные компании, где описанных проблем нет. Частный опыт не может быть аргументом для описания общей тенденции.
Ну не знаю. Работал и в конторах, где работал DevOps и в конторах, где работал Agile, и, хотите верьте, хотите-нет, там, где работало и то и другое. Кстати, в большинстве случаев, сначала по шапке получало высокое начальство, и только потом, уже от него, раздача спускается на уровень разработчиков и девопсов. С уменьшеной силой и то если руководство не вылетало после получения по шапке.
Опять же приведённые ошибки менеджмента, (даже если забыть, что все мы люди и ошибаемся, и таких же ошибок со стороны разработчиков я могу привести не меньше) эти ошибки нельзя оценить без контекста, без информации на стоимость разработки. Та же старая версия хадупа заместо рефакторинга могла сэкономить/заработать фирме достаточно, чтоб не считать ошибкой(хотя скорей всего это и не так), например, в условиях, когда этих 3х месяцев просто нет.
Вобщем, резюмируя, не работает там, где на это всем начхать.
Статья в духе "Все папуасы, а я Д'арьаньян". Если ты видишь дичь, зачем делаешь? А если ты своими руками делаешь дичь, то какие к другим вопросы то? Или у вас там надсмотрщики с плетками? Или мож паспорт не отдают?
Отчего сам не рулишь, если знаешь, как нужно?
По моему опыту Devops вполне себе работает, главная проблема, что нормальных девопсов не найдёшь днем с огнём. 90% так называемых девопсов обычные сис админы, которые хотят много денег за ту же работу.
Agile тоже работает при нормальном менеджменте, что и правда встречается крайне редко. Среднестатистический менеджер, к сожалению, может только ставить сроки (часто нереальные) и подгонять все, что движется и не движется.
А кого же мне пытаться нанять? Я не могу нанять методологию. Я как раз и имею ввиду то, что люди пишут в резюме, что они специалисты по Devops, а по сути даже не знают, что это. За десятерых никого работать не заставляем. У меня кросс функциональные команды примерно человек по 8, в каждой по 1 девопсу.
Странный совет. Я должен менять процессы на несколько тысяч человек, чтобы что? Не нанимать девопса?
Да нет у меня никакой агрессии. И уж явно не я виноват в том, что девопс где-то там заканчивается. У меня проблема прямо противоположная. Хотим вот мы развить девопс культуру в организации, ищем людей, которые с методологией знакомы. Что в этом плохого? А по факту получается именно так, как вы говорите. Т.е. люди по сути работают сис админами на всем готовом, с девопсом не знакомы и знакомиться не хотят. Но в резюме пишут, что они девопс-инженеры (видимо такие агрессивные как я лычки им повесили в погоне за модой) и просят 400К. И таких кандидатов 90%.
Я перестал понимать, о чем вы и что за кровавый девопс описываете) Никто никого не заставляет, девопс-инженеры такие же члены команды, как и разработчики, тестировщики и т.д., которые вместе развивают продукт.
Ну значит я в каком-то выдуманном мире живу, где со мной работают 2 девопс-инженера, на собеседования приходят люди с опытом девопс-инженера и всякие скиллбоксы проводят обучение на девопс-инженеров. Не я же это придумал, я пользуюсь привычными терминами в моей среде.
Кто запрещает договориься называть "девопс инженером" разновидность operatioons инженера, который знает devops подход и обладает навыками, часто использующимися при devops подходе?
6 баллов по 5-ти бальной системе. Именно это я и увидел, когда перешёл из маленькой конторки, которая делала продукт, но который работает, в большую Компанию, которая уже который год бредит-грезит выпуском второго поколения продукта, который был выпущен этой Компанией, когда она была ещё маленькой конторкой. И, что обидно, что кругозор менеджеров, уже чем у скаковой лошади. Даже из этой статьи, любой менеджер вынесет вывод, что дело в некомпеиентности менеджеров. И будут нанимать ещё более дорогих менеджеров. Как будто от этого новонанятые будут более компетентны. Вот готов поспорить, что ни один из менеджером не сможет сделать очевидный правильный вывод из этой статьи. Не способны они на очевидные правильные выводы.
Вечный холивар )
Как по мне - всё просто, когда смотришь на компетенции менеджера.
Девочки, мальчики, дяденьки и тётеньки не из ИТ и которые не умеют управлять, не понимают (местами) элементарных терминов из ИТ. И таких - большинство.
И самое грустосмешное, что у них з/п по рынку на уровне джунов.
Почему грусносмешное?
Да потому что почти все мои знакомые/друзья/деловые контакты из ИТ (разработка/девопсы), кто решил перейти когда-то в менеджмент, тупо "возвращаются" обратно.
Меньше нагрузка, меньше ответсвтенности, больше денег, больше свободного времени (в т.ч. и на работе).
Ну, и что хотите от тех менеджеров, которые работают на ваших проектах? Поинтересуйтесь, кто они, откуда, какой у них опыт в ИТ и всё такое. Ну, и, конечно же, какой у них опыт у управлении, в менеджменте...
И если это будет сферическое в вакууме существо с опытом работы 2-3 года или 15-20 оет, но из них в ИТ всего 1-1.5, то чего вы отних хотите?
Это как от джуна ждать архитектуру приложения и проектирование БД... Да даже и от миддла.
Почему DevOps и Agile не работают в России, часть первая, Enterprise