Comments 12
Ну так то программиста можно отправить и снег убирать, и картошку собирать. Дорогой дежурный получается - ему же как программисту платят, да? - но раз сэкономили на тестировании, нужно выкручиваться.
Этот стон у нас песней зовётся
дежурства и должны быть такими
Да, в этой яме со скользкими краями вполне комфортно и тепло. И бедолаги-руководители, и рядовые страдальцы - все при деле, все уставшие. Значит, всё не зря.
Проклятые буржуины придумали 3 уровня техподдержки, и никакой романтики:(
Он следит за состоянием приложения (или нескольких), в разработке (поддержке) которых он участвует.
Не очень понял как, разве что речь о веб разработке.
У нас дежурства по тестам были - в свой день с утра разобрать результаты ночного прогона, идентифицировать реальные новые проблемы, закинуть в ClearQuest...
Но ведь разве не всегда так начинаются дежурства? Конкретные желания по автоматизации и упрощению жизни дежурного должны материализоваться в тикеты и таким образом процесс итеративно улучшается.
Если процесс не улучшать, то сам по себе он не улучшится.
Ну... Как-то так себе. Очередной рассказ про то что в некой конторе всё делается через одно место. Совет один - если начальство не хочет ничего менять и не понимает проблемы, бежать подальше от этой конторы. Вот и всё
Какой смысл ставить на такие дежурства именно программиста? Там же программистской работы - разработки ПО - нет вообще. Это должность для поддержки/девопса/какой-то особой роли со смешением их обязанностей.
То что в статье описано, если это не выдумано - это не дежурства, это рабство с откровенным нарушением трудового законодательства. Как уже написали, бежать надо оттуда как можно быстрее.
Там же программистской работы - разработки ПО - нет вообще.
Однако 'разбираться, что именно в софтовой системе пошло не так' - считается именно задачей программиста. Кроме того, много ли пишущих программистов и тех, кто около, пишут достаточно подробную документацию, чтобы инженеры эксплуатации могли разобраться, что произошло и что чинить, не являясь этими самыми программистами хоть в какой-то степени?
То что в статье описано, если это не выдумано
Оно, может и нарушение и жудко не нравится. Но полезно хотя бы с той стороны, что пишущие программисты постигают на своей шкуре ту боль, которую причиняют эксплуатирующим их изделие.
У нас, кстати, на подобных мероприятиях (В момент внедрения/введения в эксплуатации новой версии. Ночного внедрения - дежурство было еще и ночным), участвовала вся команда, включая аналитиков.
Цель - посмотреть логи с внедрения, сказать go/no go (в последнем случае - еще проверить, что откат версии штатно произошел).
Потому что тестирование тестированием, но иногда на боевой системе что-то такое вылазит просто из за того, что полного соответствия тестового стенда и промышленной системы - добиться невозможно.
>Однако 'разбираться, что именно в софтовой системе пошло не так' - считается именно задачей программиста.
Я как-то не увидел с статье например "написания хотфикса и выкатки его на прод" (это уж не говоря о том что такая выкатка будет ночью, в обход релизного цикла без остальной команды и тестировщиков, что может пойти не так? Может вообще прямо на проде исходники править?), я видел там
>свистелка показывает превышение приложением лимитов потребление памяти, график на дашборде этого не подтверждает. Что происходит — загадка для дежурного. Но делать что‑то нужно и дежурный начинает «строить самолёт из пальмовых листьев» (отсылка к карго‑культу) — пытаться с помощью логов, графиков и загадочных переключений всего и вся добиться того, чтобы свистелка перестала свистеть,
Если вы считаете что
>пытаться с помощью логов, графиков и загадочных переключений всего и вся добиться того, чтобы свистелка перестала свистеть
То даже не знаю, что сказать.
Мне кажется очевидным что таким способом можно как максимум составить описание проблемы для хотфикса которую будут решать уже позже.
>Но полезно хотя бы с той стороны, что пишущие программисты постигают на своей шкуре ту боль, которую причиняют эксплуатирующим их изделие.
Предлагаю в таком случае вообще всю поддержку и девопсов заменить программистами тоже. Пусть программисты сами и с пользователями общаются, 24х7 всю неделю как в статье говорится.
> У нас, кстати, на подобных мероприятиях (В момент внедрения/введения в эксплуатации новой версии. Ночного внедрения - дежурство было еще и ночным), участвовала вся команда, включая аналитиков.
Так это у вас разовое мероприятие, а автор описывает постоянное. Ну и опять же при участии всей команды там явно будет не
>пытаться с помощью логов, графиков и загадочных переключений всего и вся добиться того, чтобы свистелка перестала свистеть
Статья не выдумана. Это правдивая история.
Я тоже задавался вопросом: почему на проекте сделано именно так. Пока что на ум приходит только одно - в целях экономии.
del
Про дежурства замолвим-ка слово