DevOps или как мы теряем заработную плату и будущее IT-отрасли

    Самое печальное в сегодняшней ситуации то, что IT постепенно становится отраслью, где вообще нет слова “стоп” в количестве обязанностей на 1 человека.

    Читая вакансии иногда уже даже видишь не 2-3 человека, а целую компанию в 1 лице, все спешат, тех.долг растёт, старое legacy на фоне новых продуктов выглядит совершенством, потому что в нём хотя бы есть дока и комменты в коде, новые продукты пишутся со скоростью света, но в итоге пользоваться ими нельзя ещё год после их написания, и зачастую этот год прибыли не приносит, более того, расходы на “облако” выше, чем продажи сервиса. Деньги инвесторов уходят на содержание ещё не работающего сервиса, но который уже выпустили в сеть как рабочий.
    Как пример: известная компания, чей ремастер старой игры получил самые низкие оценки за всю историю индустрии. Я был одним из тех, кто купил данный продукт, но даже сейчас этот продукт работает ужасно, и по идее ещё не должен был в таком виде выходить в продажи. Возвраты денег, падение рейтинга, огромное количество банов пользователей на форумах за жалобы на работу сервисов. Количество патчей не восхищает, а ужасает, но всё равно – продукт не юзабелен. Если этот подход приводит к таким результатам у компании, которая занимается разработкой с 91 года, то у компаний, которые только начинают свою деятельность, ситуация ещё хуже.

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

    Я часто слышу утверждение, что DevOps команд не должно быть, что это методология и т.д., но вот беда, компании почему-то перестали искать ноков, dba, инфруктурщиков и build инженеров – сейчас это всё DevOps инженер в единственном лице. Конечно, в отдельно взятых компаниях такие вакансии ещё есть, но их всё меньше. Многие это назвали развитием, я лично в этом вижу деградацию, невозможно поддерживать по всем направлениям хороший уровень знаний, и при этом успевать работать не более 8 часов. Естественно – это фантазии. В реальности, многие ITшники вынуждены работать и по 12, и по 14 часов, из которых оплачивается 8. А зачастую и без выходных, потому что «мне поставили задачу, доков нет или кривые, да ещё и денег стоит сервис», а за 1 ошибку в облаке можно в принципе не получить з\п за пару месяцев, особенно, если работаешь по ИП. Мы по факту теряем слово в бизнесе, вместе с разделением обязанностей, я всё чаще сталкиваюсь с тем, что менеджеры лезут в процессы разработки, вообще в них ничего не понимая, они путают бизнес-данные и работу приложения, в результате начинается хаос.

    Когда начинается хаос, бизнес хочет найти виновного, и тут нужно универсального виновного, повесить вину на 10+ человек сложно, поэтому менеджеры объединяют позиции, ведь чем больше обязанностей у 1 специалиста, тем проще доказать его халатность. А в условиях Agile нахождение «виновного» и порка — это основа данный методологии ведения бизнеса в менеджменте. Agile давно вышел из IT, и основной его концепции стало – требование ежедневных результатов. Проблема в том, что у узкоспециализированного специалиста не всегда будет ежедневный результат, а значит отчитаться будет сложнее, и это ещё одна причина, почему бизнес хочет «специалистов по всему». Но основная причина конечно же, это ФОТ – он основная причина всех изменений, ради надбавки люди соглашались работать за себя и того парня. Но в итоге, как и в других сферах, это просто стало теперь обязанностью, за меньшую оплату большего кол-ва предоставленных услуг.

    Сейчас можно часто увидеть даже статьи о том, что уже и разработчики должны уметь деплоить, должны заниматься инфраструктурой рядом с DevOps инженером, но к чему это приводит? Правильно – к падению качества сервисов, к падению качества разработчиков. Вот буквально 2 дня назад я объяснял разработчику, что писать и читать можно из разных хостов, а мне с пеной у рта доказывали, что никогда такого не видели, вот есть в settings orm host, port, db, user, password и всё…. Зато разработчик умеет запускать деплои, писать ямлы…. Но уже забывает про юнит тесты и комменты в коде.

    По итогу мы видим следующее – постоянные переработки, поиски решений проблем вне рабочего времени, постоянное обучение в выходные, и не для роста доходов, а для поддержки себя на плаву. Разработчики вынуждены помогать DevOps инженеру с CI/CD, а если у разработчика нет времени, тот начинает зашиваться, и менеджеры начинают компостировать мозги, а, если это не помогает увеличить желание работать сверхурочно, то применять взыскания и штрафы, человек ищет новое место работы, оставляя после себя тех.долг размером с Эверест, в результате долг начинает расти и у разработчиков, т.к. они вынуждены писать код с меньшим его рефакторингом, чтобы успеть помочь либо старому или новому DevOps инженеру, а менеджеров всё вполне устраивает, ведь виновный есть и его видно сразу, а значит основное правило при Agile в менеджменте соблюдено, виновный найден, результаты по его порке видны.

    Когда-то на ITGM я выступал с докладом «когда мы научимся говорить «нет»» — его результаты были очень показательными. Огромное число людей считает, что это слово табу, и пока мы не перестанем так считать, проблемы будут только расти.

    Частично на данную статью меня подвигла данная статья, но я позже возможно распишу её менее обходительными терминами.

    Only registered users can participate in poll. Log in, please.

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

    • 67.8%Да, сталкиваюсь регулярно306
    • 5.3%Да, сталкивался 1 раз24
    • 14.2%Не замечал64
    • 12.6%Я трудоголик, сам работаю сверхурочно57
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 110

      +17
      >что уже и разработчики должны уметь деплоить, должны заниматься инфраструктурой рядом с DevOps инженером, но к чему это приводит? Правильно – к падению качества сервисов, к падению качества разработчиков

      Имхо ровно наоборот. Когда разработчик не понимает, как работает им написанное в лайве и какова реальная цена тех косяков, что он понаписал — «качество разработчика» только падает.
        +4

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


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


        И так каждый раз, когда собираюсь что-то улучшить со своей профессиональной точки зрения, я встаю на путь в котором спасибо не скажут, а скорее наоборот — отчитают. И начинается — если задачу не удаётся решить за день, то рабочий день становится 16 часов, а рабочая неделя семидневной, чтобы поскорее завершить свой процесс и дальше делать таски, которые уже горят.


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

          +9

          Так НЕ ДЕЛАЙ? Вообще я бы в мраморе эту фразу выбил и каждому при рождении татуировку бы делал.


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


          Причем это не только про IT.

            +2

            Эта недальновидность меня поражает.


            Я могу и дальше заливать проект суперклеем по настоянию менеджера, но что будет со мной через год когда я вынужден буду грызть этот клей, чтобы в залитое место впихнуть ещё что-то?


            Нет дорогой. Я повышаю качество условий своего труда чтобы и дальше работать над усложняющейся архитектурой своего фронта́ и спасаю себя от ещё больших мук по сравнению со муками совести от незакрытых тасков.


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


            С другой стороны я могу безропотно позволять стрелять в обе ноги, двойным залпом из двух двустволок. Писать костыли, бетонировать и дублировать код. Положить болт на SOLID и вообще всё, что не касается текущей реализации, выдавать работоспособный код раньше дедлайна и вообще быть лапой. А там хоть трава не расти.


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


            К тому времени когда это произойдёт, как-то улучшится ситуация на рынке труда? Как она улучшится? Почему? Где гарантия, что наговнокодив я не решу срочно менять место работы, не оставив документации после себя — потому, что таски нужно перетаскивать, а не документацию писать? Что подумает новый человек с этого рынка труда когда откроет этот говнокод?


            Стих в тему

            Бревно (С.Баруздин)


            Лежало на пути бревно,
            Мешало путникам оно.


            Один сказал: -Нехорошо!
            Сказал — и знай себе, пошёл!


            Второй взглянул, потом вздохнул
            И то бревно перешагнул.


            А третий путник промолчал.
            Он с виду был и хил, и мал.


            Он молча скинул полушубок
            И в сторону бревно убрал.


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

              +11
              Ну то есть ты добровольно взвалил на себя еще обязанностей, без согласования с начальством и без выделения рабочих часов под это?
                0

                По разному бывает. Иногда под это получается выделить часы, иногда по своей инициативе, иногда неизвестно сколько потребуется часов.


                Звучит конечно диковато, но и позиция «мопед не мой» — тоже не очень хороша.


                Видимо хочется признания, поэтому сублимирую здесь. А ещё хочется, чтобы появился DevOps, а не просто админ, который умеет nginx и автоматизацию.

                  +3
                  Звучит конечно диковато, но и позиция «мопед не мой» — тоже не очень хороша.

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

                    +1
                    Соглашусь. Идеализм хорош, когда оплачивается (ну то есть сам по себе он всегда хорош, а ситуативно — по разному). В противном случае надо менять или свой подход к работе (на холодный бизнесовый) или работодателя. И то и то трудно…
                      0

                      Те, кто не выделил время, ответственности нести не будут никогда. Потому что те, кто выделяет время обычно машут руками и кричат: "Хочу! Хочу! Хочу!". Обычно так же это контора, где бизнесу похер на инфраструктуру, похер на разваливающиеся системы, лишь бы по бумажкам было как можно "вчерее" in production. Бизнес заставит своих работников делать все руками на бумаге, если потребуется. В таких конторах страдают вообще все: АСУ, админы, поддержка, разрабы. И в таких конторах нет DevOps, есть программист, который все сделает.
                      KasperGreen говорил про Agile, но он очевидно упустил одну маленькую деталь: эти методики ориентированы на команды, где четко разделены роли. Как минимум в пределах одной итерации.

                      0
                      Да чё там уметь, шлёп шлёп по документации и админ должен был справиться.
                    +3
                    но что будет со мной через год когда я вынужден буду грызть этот клей

                    Вот эта «та самая» причина из-за которой время работы программиста в компании, в среднем, сократилось до года или даже меньше. Это я сужу по резюме которые смотрю последние лет 7, если раньше нормой было увидеть 2-3 года работы на одном месте, то сегодня 6-12 месяцев становится нормой.

                    я иногда делаю не свою работу, с целью улучшить положение себя и других разработчиков

                    Можно к этому относится как к обучению, причем не на выдуманных задачах, а на реальных, или если это поможет зарплату повысить, или лычку получить новую.
                      +1

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

                  0
                  Так может наоборот, в таких условиях начинать писать только write-only код? Чтобы потом никто ваше место не смог занять.
                  Или другими словами, если к вам перестают относиться как к честному разработчику и пытаются применять бизнес-методы продавливания, то может надо и самому того становиться немного бизнесменом?
                    0
                    С нашей далеко не «бирюзовой» системой ведения бизнеса в стране, где зачастую «я начальник — ты дурак», легче набрать новый костяк, чем кормить старый.
                      0
                      Так такой начальник в теме не очень хорошо разбирается (они на командование заточены), поэтому его легко провести, постепенно создавая себе форпост в виде непонятного более никому кода. И когда он это поймет — будет поздно.
                    0
                    Это да, но когда на пятом собрании ты отчитываешься не о том как завершил задачи, а что продолжаешь заниматься настройкой деплоя — тебя виртуально начинают пороть.


                    Разработчику не нужно заниматься настройкой деплоя в большой команде.
                    Автоматизацией деплоймента занимается девопс или configuration engineer.
                    Но Девопс не может заранее знать что за приложение вы пишете, какие у него требования и как вообще его запустить, если оно состоит из десятка сервисов.

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

                    А девопс или инфраструктурный инженер уже занимается автоматизацией деплоймента, после чего деплой делается нажатием кнопки в CI или CD инструменте.

                    Если же компания скидывает эту обязанность на разработчиков — ну это уже проблемы компании, и вопрос нужно поднимать на менеджера.
                      0
                      Было бы неплохо, если бы разработчики хотя бы написали как билдить и перед коммитами пробовали сбилдить то что накодили.
                        0
                        достаточно требовать с разработчиков Dockerfile, а если они такое не умеют, то разжаловать в джуны.
                          0
                          Иди это нашим руклям расскажи.
                            0
                            Ищите себе нормальных руководителей
                              0
                              Без проблем, пока буду искать вы можете оплачивать финансовые потребности моей семьи)
                                0
                                0_о
                                Что еще мне ЗА ВАС сделать?
                                  +1
                                  Можете за меня повозмущяться собственным узкомыслием)
                        0
                        Если же компания скидывает эту обязанность на разработчиков — ну это уже проблемы компании, и вопрос нужно поднимать на менеджера.

                        о каком размере компании говорим?


                        Разработчику не нужно заниматься настройкой деплоя в большой команде.
                        Автоматизацией деплоймента занимается девопс или configuration engineer.

                        большая команда это тупик. Как говорится, наиболее эффективно работают команды (проектные или продуктовые) размером, что они могут съесть две большие пиццы и насытиться ) Плюс в такой команде однозначно будут люди, которые подменяют друг друга ) А не то, что "ты девопс — ты и пили пайплайн". И компании в общем-то ехало-болело как конкретно в каждой команде сделан деплой. Работает? Хорошо работает? Сбоев нет? Ну, и хорошо. Я хоть сам и за централизацию — т.к. она позволяет реально экономить много денег и не переизобретать велосипед по 10 раз, но избыточная централизация таких вещей вредна: теряется гибкость и скорость (блин, говорю почти как по методичкам эджайлистов).

                          0
                          Всё хорошо, только кроме девопсов, должны быть и те кто этим девопсам и разрабам постелит коврик — инфраструктурщики и админы. А то доходит до того, что девопс, за 100500 денег, не понимает того как работает стек TCP/IP или там DNS или не может написать элементарного правила iptables и вот тут начинается. То-есть смысл в том, что девопсы, оиентированные на разработчиков и их цикл работы, никак не могут заниматься ещё и инфраструктурой.
                            0
                            А то доходит до того, что девопс, за 100500 денег, не понимает того как работает стек TCP/IP или там DNS или не может написать элементарного правила iptables и вот тут начинается

                            это не девопс, а самозванец ) И не нужно называть инженера девопсом — это баззворд, который ничего не означает, тем более, если Вы принимаете, что devops это методология или философия. У нас шутят, что девопс разве что картриджами не занимается....


                            инфраструктурщики и админы.

                            согласен с тем, что может существовать инфраструктурная команда, которая поддерживает платформенное решение. А может, что ее и нет, если продуктовая команда деплоится, например, в облако (ну, ок, поддержка облака все равно никуда не девается — она по сути на стороне провайдера, но как будто ее и нет).


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

                            не уверен, что это верный тезис.


                            Вообще посмотрите
                            http://devopstopologies.ru/
                            https://www.engineerbetter.com/blog/kill-the-devops-team/
                            Очень занимательно.

                              +2
                              Бизнес решил иначе, чаще всего DevOps это такой поисковик серебряных пуль, который заменит и сетевика, и dba, и инфраструктурщика, а иногда ещё и за разрабов всю инфраструктуру продумает, чтобы можно было дополнительный код не писать.
                                0
                                разрабов

                                называй их кодерами, а не разрабами — я что-то сомневаюсь, что эти люди достойны гордого звания "разработчика" или "SWE"

                                  0
                                  И ведь самое страшное, такие люди есть.
                                    0
                                    А чего в этом страшного?
                                      0
                                      Форма речи такая.
                                  0
                                  Так девопс это и есть инфраструктурный админ.

                                  Просто есть глобальные решения внутри компаний, которые предлагают какой-то SAAS, и там сидят ускоспециализированные админы.
                                  А есть девопсы, которые автоматизируют CI/CD, помогают улучшить и автоматизировать SLDC, контролируют релизы. Если они при этом пользуются готовыми SAAS, не обязательно в них разбираться глубоко.
                                  0
                                  большая команда это тупик

                                  Большая команда нужна для больших проектов.
                                  MS Office не может написать 10 человек. Для этого нужно гораздо, гораздо больше. А для эффективности, их можно делить на мелкие команды, которые занимаются отдельными компонентами. Девопс не обязательно нужен для каждой команды, ведь продукт один, поэтому команда инфраструктурных инженеров может совместно поддерживать несколько команд разработчиков.

                                  В маленьких командах вопрос девопса нет особого смысла поднимать, поскольку там SDLC несложный.
                                    0

                                    Так в том-то и дело, что тот же ms office явно разрабатывался помодульно. Отдельными "командами".


                                    Девопс не обязательно

                                    Вообще забудьте это слово ) с одной стороны — в каком-то смысле у ms было больше девопса, чем есть сейчас у многих (почитайте про то, как они разрабатывали windows — там были все те же проблемы с тем, что хотели одно, получали другое, да и по тому же интерфейсу была куча итераций), а с другой стороны его в нынешнем понимании там не было. Тем более "девопс инженеров". Да и опять же — есть роли build engineer, release engineer, configuration engineer…
                                    SDLC — да. Ребята реализовали. Кажется именно они у истоков этого термина (и подхода) стояло. А иначе и не могло быть )
                                    Ну, и вообще есть определенная разница между коробочной разработкой (как ms office) и разработкой своего же сервиса ( девопс как направление появился именно как ответ на вызов, проблемы разработки и поддержки одними людьми — именно на пике бума веб сервисов).

                                  +1
                                  Разработчику не нужно заниматься настройкой деплоя в большой команде.

                                  Мир состоит не только из больших команд. Более того, больших не так уж и много...

                                  +3
                                  И начинается — если задачу не удаётся решить за день, то рабочий день становится 16 часов

                                  Зачем? Сегодня не успели — делайте в следующий рабочий день.

                                    0

                                    Присоединяюсь. Здоровье — оно одно на всю жизнь, а работ разных много. В том числе без необходимости переработок.

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


                                    Что то не то в головах ваших старших технических специалистов, которые так организовали вашу работу.

                                    Индивидуальная многодневная настройка деплоя вместо разработки?

                                    Бойлерплейтов да Кибернетсов на вас нет.

                                      0

                                      Если проект типовой — да, бойлерплейты. Если нет, то все равно придется настраивать пайплайн индивидуально.
                                      Кубернетес? В каждый дом? Нет, увольте, не надо так. Каждой задаче — по своему инструменту.

                                        0
                                        Если нет, то все равно придется настраивать пайплайн индивидуально.

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

                                        Что это за индивидуальная настройка пайплайна 5 дней на готовом бойлерплейте?
                                        Кубернетес? В каждый дом? Нет, увольте, не надо так. Каждой задаче — по своему инструменту.

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

                                        Если вы не можете их использовать, так, может, и деплой автоматизированный полностью на ваших масштабах и не нужен?
                                  +1

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

                                    –5

                                    Ну вот :) Так и появляются неадекватные интервьюверы-фашисты, гнобящие всех, у кого пустой гитхаб.


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

                                      –1

                                      Даже людям без пет-проектов и гитхаба обычно есть что рассказать на интервью, и они могут оказаться лучше — вклад в OSS и свои проекты не делают разработчика хорошим сами по себе — дело в другом: по пет-проектам и вкладу в OSS складывается первое впечатление: i.e. перед вами активный контрибьютор в условный rust, пишущий по выходным своего убийцу твиттера, и просто разработчик без вклада в OSS и без своих проектов — интереса к первому не будет больше?
                                      И мне в последние лет 7 не доводилось работать с людьми не имеющими ни того, ни другого, что тоже влияет на мою предвзятость.

                                        +8
                                        я лучше возьму человека, который по выходным катается на велике, гуляет с ребенком по парку или мочит монстров в дум. Как-то за его психику и общее вливание в коллектив спокойнее.
                                          –3

                                          Как активное участие в OSS сообществе и пет-проекты связаны с невозможностью растить детей, играть в дум и прочим? Я, например, не считаю себя новым Маском, однако вполне успеваю и работать, и учиться в вузе, и читать/гулять/пилить свои проекты в свободное время. А вклад в OSS (помимо того, что моя работа в принципе — FOSS, тут повезло) это нормальный побочный эффект работы с кодом: тебе надо сделать для работы что-то, что библиотека, которую ты используешь, не умеет — ты берешь и делаешь, а потом сабмитишь изменения в ту библиотеку (в некоторых компаниях после согласия менеджмента, но обычно это лишь формальность).

                                            +1
                                            Как активное участие в OSS сообществе и пет-проекты связаны с невозможностью растить детей, играть в дум и прочим?

                                            Временем они связаны, разве не очевидно? На все это нужна уйма времени и сил. Особенно на маленьких детей :) Добавить к этому обычные проблемы обычных людей — ремонты, походы в магаз, хобби какое + совершенно нормальное желание просто поваляться на диванчике под сериальчик — и вот как-то уже и времени на все не хватает.


                                            однако вполне успеваю и работать, и учиться в вузе, и читать/гулять/пилить свои проекты в свободное время

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


                                            Все было новым, все казалось очень захватывающим и интересным. А главное важным. Просто как и качество моих проектов, так и уровень погружения в OSS — были довольно унылые :) Когда я бросил "распыляться" на всё, в том числе и на OSS и сконцентрировался на работе — качество моего софта существенно выросло и мне за это стали платить куда больше денег.

                                              0

                                              Не очевидно благодаря большому числу знакомых либо активно участвующих в OSS, либо делающих свои проекты, при этом имеющие время на семью, хобби и сериал по выходным.


                                              что мне теперь, жопу рвать

                                              да хоть каждый день сериалы смотрите — дело ваше. Для кого-то и английский язык учить, или новый ЯП — "жопу рвать" и оно не нужно. А другим это просто интересно.


                                              был моложе… даже при недостатке сна...

                                              я не то, чтобы особо молод, да и сплю по 8 часов практически без исключений


                                              когда я бросил распыляться

                                              проблемы тайм-менеджмента


                                              качество выросло, стали платить больше

                                              по сравнению с вами, распыляющимся? Ну логично.

                                                +1
                                                Возможно у человека просто другая скорость когнитивных возможностей из-за физиологических особенностей.
                                              0
                                              А у Вас есть жена, дети? Если есть, то я буквально преклоняюсь перед Вами. Ну или Вы всё скидываете на жену, но тогда Ваш брак долго не протянет.
                                              А если детей и жены нет… То да, я тоже такой был в универе. И кучу своих проектов пилил, и английский изучал, и в педагогический универ через дорогу к девчёнкам бегал, и в выч. центре универа подрабатывал, и проекты за деньги на стороне пилил, и монстров на компе отстреливал. А вот когда появились жена, двое малолетних детей, ипотека, тёща со своей дачей, нормальная постоянная 8-и часовая работа — всё исчезло.
                                                0

                                                Есть жена, есть свои проекты, есть много путешествий (да, сейчас меньше, но все же есть), есть постоянная фуллтайм работа и дистанционная вышка в процессе. За наш брак не беспокойтесь — у нас все прекрасно, а жена занимается любимым делом.
                                                Дети не пугают; ипотека (в России) — нет, спасибо; теща прекрасная, огороды нас с женой не привлекают и мы там никому не сдались.

                                                  0
                                                  Жена и жена и дети — это ОЧЕНЬ разные вещи.

                                                  Скажем так. Закончить школу и поступить в институт — жизнь несколько поменяется.
                                                  Закончить школу и устроиться работать — жизнь несколько поменяется.
                                                  Жениться — жизнь несколько поменяется.

                                                  А вот дети — это другая жизнь.
                                                    0
                                                    А вот дети — это другая жизнь.

                                                    в прямом и переносном смыслах, внезапно

                                                    0
                                                    Т. е. детей нет и все могут спокойно заниматься любимым делом. Это замечательно. Наслаждайтесь, пока не появятся дети.
                                                      0

                                                      Ну раз вы перестали всем этим заниматься исключительно по причине появления детей — рад за вас, но значит вам есть что рассказать о своем прошлом, верно? Это тоже много значит.

                                                      0
                                                      Есть жена, есть свои проекты, есть много путешествий (да, сейчас меньше, но все же есть), есть постоянная фуллтайм работа и дистанционная вышка в процессе.

                                                      И сколько, конкретно, времени в день у вас уходит на жену, на свои проекты, на путешествия, на работу, на вышку?

                                                        –1

                                                        На жену — постоянно, мы работаем дома, вместе круглосуточно.
                                                        На проекты — час-два по будням, на выходных по обстоятельствам.
                                                        На путешествия в среднем 2 дня на перелеты/обустройство и дальше по паре часов в день на изучение города плюс выходные по обстоятельствам. Последний раз в путешествие ездили на днях на неделю и даже с учетом сильно запутанного и затратного по времени процесса выезда и въезда в РФ, удалось и поработать 40 часов, и город посмотреть, и свои проекты поделать, и полтора дня потратить на общение с ответственными лицами по миграционным вопросам. Хотя у меня сейчас "каникулы" в универе, наверное в этом все дело? :)
                                                        На работу — 30-50 часов в неделю (последние пол-года не меньше 40)
                                                        На вышку около 8 часов в неделю и 1-2 полных дня в месяц на подготовку/доработку tutor-marked assignment, а также 3-5 дней на подготовку/доработку end-of-module assignment.

                                                          0
                                                          На работу — 30-50 часов в неделю (последние пол-года не меньше 40)
                                                          На вышку около 8 часов в неделю

                                                          Смотрите, простая математика: 8 часов в день вы тратите на работу, в среднем полтора часа на вышку, полтора часа на проекты. Вас «нет дома» 11 часов. А ещё завтрак/обед/ужин, одеться/умыться/побриться/почистить зумки, сходить в магазин и т.д… Я понимаю, сидя в одной комнате с женой 24 часа в сутки, желания вечером пойти с ней погулять по городу не возникнет, но просто примите к сведению, что ваш образ жизни весьма «самобытный», и крайне мало кому подойдёт. Пет-проекты, вклады в опенсурс по вечерам — это по-большей части дело для одиноких холостяков или молодёжи.
                                        • UFO just landed and posted this here
                                            +3
                                            Помоему соль в том, что Agile должен быть не про это
                                            основное правило при Agile в менеджменте соблюдено, виновный найден
                                              +1

                                              Про «уровень счастья разработчика»? Насколько ему удобно и продуктивно работать? Как ему в этом деле помочь? Да?


                                              [Ну пожалуйста. Скажите — да.]

                                                +1
                                                agile — это получение value через постоянную адаптацию.
                                                в scrum вообще не должен выделяться персонализированный виновный, это командная ответственность.
                                                +1
                                                Я так понимаю цель статьи — поплакаться?

                                                Какой бы менеджмент ужасный не был — всё в твоих руках. Либо меняй атмосферу на работе и доказывай обратное — либо меняй работу. Это в принципе так, не только с данной темой.

                                                Что касается DevOps, я с Вами не согласен.
                                                Я не считаю, что DevOps должен делать всё, как Вы описываете. Появилась под-ниша в разработке ПО, а не как Вы говорите, нашли «эникейщиков».
                                                Эникеи всегда были — я их называю философами. Смотрят широко но не глобоко. И не стоит их путать с DevOps.

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

                                                DevOps, как и сокращение и гласит Development & Operations тоже свое рода филосов, сконцентрировавшийся на снижении порога между разработчиками и сисадминами. При том для меня (как я и есть) DevOps должен иметь больше опыта из разработки чем сисадмина.

                                                Короче, то что Вы написали, отношу к «накипело». Никакой ценности от этой статьи не увидел.
                                                Вашу аналогию считаю не оправданной.

                                                Работать по 14 часов за оплаченные 8 — как себя нужно не ценить, что бы такое позволять...? Отсюда и остальное становится более понятным… но это не точно…
                                                  0
                                                  Почему DevOps это человек? Это же методология. У нас вот DevOps это целая группа людей: одни отвечают за CI, другие за железо, третьи за опеншифты, четвёртые за деплоймент и т.д. Каждый делает свою работу хорошо, а все вместе они DevOps Team. И никаких проблем ни у кого нет. До тех пор, пока девопсами будут считать конкретных людей, будет бардак и постоянно сорванные сроки всего и вся, ибо один человек физически не может хорошо разбираться во всех этих отраслях.
                                                    0
                                                    Каждый делает свою работу хорошо, а все вместе они DevOps Team.

                                                    нет, это антипаттерн. Я ниже давал две ссылки, почему если у Вас DevOps Team, то DevOps у Вас не будет никогда.


                                                    http://devopstopologies.ru/
                                                    https://www.engineerbetter.com/blog/kill-the-devops-team/


                                                    продублировал, чтобы Вы не искали )

                                                      –1
                                                      Но он у нас есть. И без проблем из поста.

                                                      Все эти статьи похоже работают в фантазиях авторов или на очень мелких продуктах/проектах. У нас на 4000 разработчиков, несколько сотен CI проектов и тысячи аппликейшенов на опеншифтах с разными наборами конфигураций. Если бы каждый разработчик обязан был с этим разбираться, это просто десятки тысяч дней оверхэда на решение различного рода проблем.
                                                      +1
                                                      я не понял, где я Вам противоречил...?

                                                      Заминусуют полюбому, но я потсараюсь достучаться
                                                        0
                                                        Может быть тут проблема именно в терминах. Например есть буддизм и есть буддисты — люди, которые буддизм исповедуют. За счет наличия в языке двух слов мы не путаем религию и ее адептов. Другой пример — scrum master, никто же не рассказывает, что scrum master это не человек, так как ценности скрама должным разделять все участники команды. А вот devops, это обе вещи сразу, и набор практик и человек, который призван способствовать их внедрению. О том, что мы в каждом конкретном случае имеем в виду собеседник должен догадываться по контексту и это иногда приводит к недопониманию, но это не означает, что нельзя нанять человека, который принесет в вашу команду/компанию ценности и практики devops.
                                                          0
                                                          который принесет в вашу команду/компанию ценности и практики devops.

                                                          несомненно, но тогда так и называйте его — devops-евангелист, devops-коуч, методист по внедрению devops, ну, не знаю, в конце-концов ))) но никак не devops-инженер

                                                      –10

                                                      Ноков не ищут потому что есть Prometheus Alert Manager + PagerDuty.
                                                      DBA не нужны потому что повсеместно NoSQL.
                                                      Билд инженеров потому что девелоперы сами делают helm create и степы для github actions могут скопипастить из мануала.


                                                      А если серьёзно — чем по вашему должен заниматься идеальный девопс инженер? Что является истинно вашей задачей?

                                                        +3
                                                        DBA не нужны потому что повсеместно NoSQL.
                                                        Можете, пожалуйста, развернуть эту мысль? Я не особо понимаю как NoSQL бд отменяют DBA.
                                                          +1

                                                          Вы точно не путаете NOC (которые сетевики) и дежурную on-call смену?

                                                            0

                                                            Может и путаю. В моей практике ноки всегда были на звонке, следили за продом, открывали страницы сайта, смотрели в графану и заббикс, подымали разработчиков если что. У них были кое какие инструкции как что рестартануть, но на простейшие кейсы.


                                                            Upd: Ввиду лимита на 1 комент в час добавлю сюда, что они не спят ночью как дежурные админы. Они 24/7 мониторят и это очень похоже на определение noc

                                                              +3

                                                              это не noc'и, а обычная "дежурная on-call смена".
                                                              Это примерно на том же уровне, что давайте переименуем админов в девопсы без изменения обязанностей ) суть-то не в названии, а в функции, в роли.

                                                                0
                                                                Во первых вы путаете сетевых инженеров и дежурных инженеров.
                                                                NOC — центр сетевых операций — Network operations center.

                                                                Во вторых, если у вас есть есть инструкции на простые кейсы и их выполняют дежурные инженеры, вы спускаете бюджет в унитаз. Автоматизация 1 инструкции на ансибл занимает максимум час, проще не инженеру регулярно платить, а за код 1 раз заплатить. Ведь у вас всё равно есть мониторинг и это ваши вычислительные ресурсы на которых вы можете выполнить этот код.
                                                                  0
                                                                  Во вторых, если у вас есть есть инструкции на простые кейсы и их выполняют дежурные инженеры, вы спускаете бюджет в унитаз.

                                                                  Скорее соглашусь. Действительно нужно автоматизировать. Но только лишь с учётом того, что реальный мир сильно более многообразный, чем предполагают инструкции.


                                                                  Автоматизация 1 инструкции на ансибл занимает максимум час,

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

                                                            +2
                                                            Все понятно, непонятно почему близзов (точнее Активижн)-халтурщиков зацензурили(= Но там ситуация другая, тех людей, из 91, к сожалению, уже нет.
                                                              0
                                                              А я думал, это про третьих героев)
                                                              +6
                                                              Так девопс затем и нужен, чтобы одному работать за десятерых. Причем без особого, нужно заметить, напряга.
                                                              Раньше был тяжкий бареметал провайжнинг — теперь два скрипта на терраформе. Раньше сервер поднимали за месяц — теперь за 4 минуты. Девопс — это сисадмин, который не сидит в ожидании «пожалуйста подождите», а конкретно работает большую часть своего времени.

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

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

                                                                бареметал провижионинг никуда не делся ) не все могут и не все хотят идти в облако. И в любом случае под капотом любого облака те же железки.

                                                                  0
                                                                  Именно. Но почему-то в современном мире об этом все успешно забыли.
                                                                    0
                                                                    Очень даже делся.
                                                                    Вместо классического подхода к СХД теперь всюду multi-tier. Рейды в прошлом, шпиндели потихоньку тоже остаются только для специфических задач.
                                                                    Провайжнинг физического хоста теперь сводится к конфигурации iscsi boot target в bios setup, остальное само. Образы ОС для этих хостов тоже собираются сами и тестируются тоже сами. Обновления фирмварей и биосов идёт напрямую от вендора и ставится в течение 8 часов после выхода новых версий. Хотите 10% тестовую группу — пожалуйста, хотите тайринг 10-30-50-100 — пожалуйста. Любой каприз!

                                                                      0
                                                                      И это правильно, потому что сложность надо уменьшать, а объёмы увеличивать. Но вот вендорам я бы паяльники повставлял за их обновы.
                                                                    0
                                                                    Тут такое дело, у меня 20 файлов для cobbler для maas. Если не позволять делать грязь руководителям, то сеткой тоже рулить просто, в большинстве случаев она будет плоской. А вот если этого не достаточно, тогда нужны noc'и и инфраструктурные инженеры.
                                                                      0

                                                                      Это хорошее решение, никто не спорит. И нужно стремиться к максимальной автоматизации.


                                                                      Но бывают ситуации:


                                                                      1. Ты пришел, уже есть Легаси. Зоопарк.
                                                                      2. Чего там с мультидц? Ты сам-то умеешь в динамическую маршрутизацию? Bgp? Ospf? Mpls? L2/l3vpn? И все их тонкости? Вот только честно. А то это на картинках в букваре все видели. Конечно, зачастую это не мешает решать бизнес задачи и без этого ) но всякое бывает. И, кстати, одно из последних предложений о работе подразумевало именно хорошие навыки сетевого инжиниринга.
                                                                      3. Нельзя говорить руководителю "нет" — это как красная тряпка. У них в головах иногда рождаются странные идеи и это нужно прям на корню подрубать, но прям нужен очень грамотный софтскиллз. Предложить альтернативу. Аргументировать свою точку зрения.
                                                                        0
                                                                        Но бывают ситуации:

                                                                        Ты пришел, уже есть Легаси. Зоопарк.


                                                                        Это совершенно рядовая нормальная ситуация.

                                                                        Мы не потому сейчас имеем кучу крутого ПО, что нынешние программисты круты.

                                                                        Прошлые программисты, в среднем, как раз были более круты, они были типично научными работниками, а нынешний типичный программист просто ремесленник.

                                                                        Мы имеем крутое ПО на сегодня потому что многие и очень многие вещи написаны до нас.

                                                                        То есть легаси — это совершенно нормально и естественно.

                                                                        Ты пришел, уже есть Легаси. Зоопарк.


                                                                        Бывает, конечно, что до тебя на проекте работали обезьянки.
                                                                        Но, как правило, это ровно такие же люди как и ты.
                                                                        И то, что ты оставишь после себя будет восприниматься последующими коллегами как ровно такой же говнокод, как и то как ты воспринимаешь работу предшественников.

                                                                        Это совершенно обыденная ситуация.

                                                                        Бизнесу не нужно красиво.
                                                                        Бизнесу нужно чтобы работало уже вчера.
                                                                        Иначе у бизнеса не будет денег на твою зарплату.

                                                                        И, строго говоря, бизнес тебе не последние штаны отдает на зарплату, поэтому если проект работает, но слишком дорог в поддержке — бизнес не загнется.

                                                                        А вот если проект не говнокодный, идеально написанный, но стартовал на 2 года позже необходимого бизнесу из за слишком уж тщательной разработки — то денег на зарплату тебе бизнес уже не сможет заработать.
                                                                          0
                                                                          Прошлые программисты, в среднем, как раз были более круты, они были типично научными работниками, а нынешний типичный программист просто ремесленник.

                                                                          +


                                                                          Мы имеем крутое ПО на сегодня потому что многие и очень многие вещи написаны до нас.

                                                                          +
                                                                          Ну, либо уже понятно как решать какую-то проблему. Мы действительно ездим на технологиях 30-летней давности.


                                                                          И то, что ты оставишь после себя будет восприниматься последующими коллегами как ровно такой же говнокод, что ты воспринимаешь работу предшественников.

                                                                          +
                                                                          вполне возможно, что "будущий ты" тоже с ужасом взглянет на артефакты, созданные "настоящим тобой".

                                                                          0
                                                                          Мультидц это уже не уровень 1-2 девопсов, там уже точно нужны ноки.
                                                                    0
                                                                    ., но вот беда, компании почему-то перестали искать ноков, dba, инфруктурщиков и build инженеров – сейчас это всё DevOps инженер в единственном лице.

                                                                    Всё очень просто: соотношение компаний, которым реально есть чем занять таких узких специалистов, как dba и build-инженер к компаниям, в которых они 90% своего времени не будут делать ничего, примерно одна к к десяти тысячам. Цифра, конечно, условная, но зуб даю на отсечение, порядок я угадал.
                                                                    В общем случае «узкий, но глубокий» специалист по каким-то инфраструктурным направлениям в разработке ПО и не требуется. Нужен как раз DevOps, который знает всё, но в общих чертах. Он может настроить запуск скриптов на SQL-сервере, но ему не нужно уметь в тонкий тюнинг производительности. Он может настроить автоматическую сборку и деплой, но ему не нужно знать все тонкости настройки платформы сборки на уровне build-инженера, потому как такие вещи — это обычно разовая работа, и на крайняк можно погуглить, когда надо, сделать, и через полгода забыть.
                                                                      –4

                                                                      Видел я этих ноков, и ДБА видел: и правильно делают, что не ищут их теперь. Про всю эту шайку давным-давно был доклад от известного русского девопс-евангелиста Аркадия Райкина. Называется «Кто сшил костюм?», меньше трёх минут.

                                                                        +1
                                                                        Если в вашей компании ищут виновного вместо анализа постмортема — тогда время менять компанию.
                                                                          0
                                                                          Такие решения я видел в стартапах и компаниях где начальник действительно СТО. В компаних же где bloody enterprise (а там зачастую платят больше и скиллов перенять можно больше, если только не мертвый легаси) балом правят управленцы, которым надо найти крайнего и заработать плюшку на погоны от верхушки пирамиды.
                                                                            0
                                                                            Перенимать там нечего, изнутри ответственно заявляю.
                                                                              0

                                                                              По-разному бывает, ну, и не стоит в госухах работать )

                                                                                0
                                                                                Стоит, иначе так и будем плеваться на них. А ты приди и изнутри измени всё.
                                                                                  +1
                                                                                  А зачем? Вот когда измениться политическая ситуация и тебе будут платить миллионы, чтоб ты изменил — тогда да
                                                                                    0
                                                                                    Не все получают миллионы, а зарплата там рыночная.
                                                                                      0
                                                                                      зарплата там рыночная.

                                                                                      это не соответствует действительности (ваш бывший коллега из госов). Возможно, что есть госы с рыночной з/п или околорыночной з/п, но не нужно обобщать.

                                                                                        0
                                                                                        Да у госов сейчас зачастую вилка выше чем у частников, особенно вне Москвы.
                                                                                          0

                                                                                          Т.е. ты хочешь сказать, что условная галера типа EPAM или Luxoft дает денег меньше, чем госы в условном Нижневартовске? Ну, ок

                                                                                            0
                                                                                            Очень многие госы (я из Москвы и говорю за Москву) дают такую же вилку как на рынке, галеры обычно меньше рынка платят.
                                                                                              0
                                                                                              как не смешно но да, в условном Воронеже некоторые госы платят больше чем люкс и т-системс
                                                                                            0
                                                                                            Так раз есть с рыночной, почему бы изнутри не исправить? По образу все остальные подтянутся, там же сарафан на всю катушку работает.
                                                                                              0

                                                                                              Что исправить? Моя ваша не понимай. Рядовой инженер на зарплаты не влияет. Разве что ногами ))) пойти туда, где платят лучше.

                                                                                                –1
                                                                                                Исправить говнолепство, кривое планирование, внедрить туда современные методологии для улучшения качества продуктов и ускорения производства.
                                                                                                  +1
                                                                                                  Вот когда тебя за миллоны поставят руководить там IT — тогда и поменяешь
                                                                              0

                                                                              В мелких фирмах нужны мастера на все руки, потому что команду узких спецов просто не чем загрузить.
                                                                              Когда у фирмы 100500 проектов тогда узкие спецы всегда будут при работе и ни когда не будут простаивать.
                                                                              Но в целом, если не устраивает организация работы, то зачем продолжать?
                                                                              Всегда можно уйти

                                                                                +1

                                                                                Специально зарегестрировался чтобы написать вам. Работаю я не в вашей сфере, но ситуация была подобная. Я переживал за продукт, старался всё сделать как лучше, буквально ночами не спал. Как итог со временем из-за постоянного напряжения и недосыпания я стал "косячить", а руководство меня за это, естественно, наказывало. Но посмотрев на сослуживцев из своей команды я решил поменять своё отношение к работе. И о чудо, "косяков" стало меньше, свою работу я стал выполнять лучше, а на не свою "болт положил", зарплата увеличилась, а отношение начальства ко мне стало лучше. А за "косяки" уже начали наказывать тех людей, кто был виноват в их появлении. Как итог, перестаньте выполнять за других их работу, деньги они получат (или не получат) за свою работу в любом случае, а у вас жизнь будет гораздо спокойнее.

                                                                                  –1
                                                                                  Потому, что разработчик должен разрабатывать, и результат работы разработчика — это проект программы, техническая документация, а не программа.

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

                                                                                    Only users with full accounts can post comments. Log in, please.