Привет, Хабр! Десять лет я поддерживаю Highload ИТ системы. Не буду писать в этой статье о проблемах настройки nginx для работы в режиме 1000+ RPS или другие технические вещи. Поделюсь наблюдениями о проблемах в процессах, которые возникают в поддержке и эксплуатации таких систем.
Техподдержка не ждет пока прилетит заявка с содержанием «Какого Почему… сайт опять не работает?». Поддержка через минуту после падения сайта уже должна увидеть проблему и начать её решать. Но сайт — вершина айсберга. Его доступность ставят на мониторинг одним из первых.
Как быть с ситуацией, когда остатки товаров интернет-магазина перестали приходить из ERP системы? Или CRM система, которая рассчитывает скидки для клиентов перестала отвечать? Сайт-то при этом с виду работает. Условный Zabbix получает свой 200 ответ. Дежурная смена не получила никаких уведомлений от мониторинга и радостно досматривает первую серию нового сезона «Игры престолов».
Часто мониторинг ограничивается только измерением состояния памяти, оперативки и нагрузкой процессоров серверов. Но для бизнеса гораздо важнее получить доступность товара на сайте. Условное падение одной виртуальной машины в кластере приведет к тому, что трафик перестанет на него идти и возрастет нагрузка на другие сервера. Деньги компания не потеряет.
Поэтому помимо мониторинга технических параметров операционных систем на серверах нужно настраивать бизнес-метрики. Метрики, которые напрямую влияют на деньги. Различные взаимодействия с внешними системами ( CRM,ERP и прочие). Количество заказов за определенный промежуток времени. Успешные или не успешные авторизации клиентов и другие метрики.
Любой сайт или мобильное приложение с годовым оборотом более миллиарда рублей взаимодействует с внешними системами. Начиная от вышеупомянутых CRM и ERP и заканчивая передачей данных о продажах внешней Big Data системе анализа покупок и предложения клиенту товара, который он точно купит ( на самом деле нет ). У каждой такой системы есть своя поддержка. И часто общение с этими системами вызывает боль. Особенно когда проблема глобальная и нужно анализировать её в разных системах.
Какие-то системы дают телефон или telegram своих админов. Где-то нужно писать письма менеджерам или ходить в баг трекеры этих внешних систем. Даже в разрезе одной большой компании разные системы часто работают в разных системах учёта заявок. Отследить статус заявки порой становится невозможно. Ты получаешь заявку в одной условной Jira. Затем в комментарии этой первой Jira ставишь ссылку на задачу в другой Jira. Во второй Jira в заявке кто-то уже пишет комментарий, что нужно позвонить условному админу Андрею, чтобы решить вопрос. И так далее.
Оптимальный вариантом решения такой проблемы было бы создание единого пространства для общения, например в Slack. Приглашение в него всех участников процесса эксплуатации внешних систем. А так же единого трекера, чтобы не дублировать заявки. Заявки должны отслеживаться в одном месте, начиная от оповещения мониторинга до вывода решения багов в прод. Вы скажете, что это нереально и у вас так исторически сложилось, что мы работаем в одном трекере, а они в другом. Появлялись разные системы, у них были свои автономные ИТ команды. Согласен и поэтому проблему нужно решать сверху на уровне CIO или product owner.
Каждая система, с которой вы взаимодействуете должна оказывать поддержку как услугу с четким SLA на решение проблем по приоритетам. А не тогда когда у условного админа Андрея найдется для вас минуточка.
У каждого на проекте ( или продукте ) есть такой человек, уход в отпуск которого вызывает у начальства судороги? Это может быть devops инженер, аналитик или разработчик. Ведь только devops инженер знает, на каких серверах установлены какие контейнеры, как перезагрузить контейнер в случае проблемы да и вообще любая сложная проблема без него не решается. Аналитик — единственный знает как работает ваш сложный механизм. Какие потоки данных куда идут. При каких параметрах запросов в какие сервисы, какие мы будем получать ответы.
Кто быстро поймет почему в логах ошибки и оперативно пофиксит критичный баг в проде? Конечно тот самый разработчик. Есть и другие, но почему-то только он понимает как устроены разные модули системы.
Корнем этой проблемы является отсутствие документации. Ведь если бы все сервисы вашей системы были бы описаны, то можно было бы разобраться с проблемой и без аналитика. Если бы devops выделил из своего плотного графика пару дней и описал бы все сервера, службы и инструкции по решению типовых проблем, то проблему в его отсутствии можно было бы решить и без него. Не нужно в отпуске быстро допивать своё пиво на пляже и искать wi-fi для решения проблемы.
На крупных проектах компании не скупятся на зарплату разработчикам. Хантят дорогих мидлов или сеньёров с аналогичных проектов. С поддержкой ситуация немного иная. Эти расходы всячески пытаются сократить. Компании нанимают недорогих вчерашних эникейщиков и смело идут в бой. Такая стратегия возможна, если речь идет сайте-визитке какого-нибудь завода в Зеленограде.
Если речь идёт о крупном интернет-магазине, то каждый час простоя стоит больше чем месячная зарплата админа-эникейщика. Возьмем за отправную точку 1 миллиард рублей годового оборота. Это минимальный оборот любого интернет-магазина из рейтинга ТОП-100 за 2018 год. Разделим эту сумму на количество часов в году и получим более 100 000 рублей чистых потерь. А если не считать ночные часы, то можно смело увеличивать сумму в два раза.
Но деньги ведь не главное, да? (нет, конечно главное) Есть еще репутационные потери. Час падения известного интернет-магазина может вызвать как волну отзывов в социальных сетях, так и публикации в тематических СМИ. А разговоры друзей на кухне в стиле «Не покупай там ничего, у них сайт постоянно не работает» вообще не поддаются измерениям.
Теперь к ответственности. В моей практике был случай, когда дежурный администратор не среагировал вовремя на оповещение системы мониторинга о недоступности сайта. В приятный летний пятничный вечер и сайт одного известного в Москве интернет-магазина тихо лежал. В субботу утром продакт этого сайта не понял почему сайт не открывается, а в чатах поддержки и срочных оповещений в Slack тишина. Такая ошибка стоила нам шестизначной суммы, а этому дежурному работы.
Ответственность — навык который трудно развить. Он или есть у человека или нет. Поэтому на собеседованиях я стараюсь выявить её наличие разными вопросами, которые косвенно показывают привык ли человек брать ответственность на себя. Если человек отвечает, что выбрал ВУЗ, потому что так сказали родители или меняет работу из-за того, что жена сказала, что он мало получает, то с такими людьми лучше не связываться.
Когда на продуктиве в процессе эксплуатации у пользователей возникают несложные проблемы, то поддержка решает их своими силами. Пытается воспроизвести проблему, анализирует логи и так далее. Но что делать когда на проде всплыл баг? В этом случае поддержка заводит задачу на разработчиков и вот тут начинается самое интересное.
Разработчики постоянно перегружены. Они занимаются созданием новых фич. Фиксить баги с прода занятие скажем не самое интересное. Горят сроки для завершения очередного спринта. А тут приходят неприятные люди из поддержки и говорят: «Срочно бросай всё, у нас проблемы». Приоритет таких задач минимальный. Особенно когда проблема не самая критичная и основной функционал сайта работает, и когда релиз-менеджер не бегает с выпученными глазами и не пишет: «Срочно внести эту задачу в ближайший релиз или хотфикс».
Задачи с обычным или низким приоритетом переходят из релиза в релиз. На вопрос «Когда задача будет выполнена?» ты будешь получать ответы в стиле: «Прости, сейчас много задач, спроси у тим лидов или релиз менеджера».
Проблемы на продуктиве имеют больший приоритет, чем создание новых фичей. Плохие отзывы не заставят себя ждать, если пользователи будут постоянно натыкаться на баги. Испорченную репутацию восстанавливать трудно.
Вопросы взаимодействия разработки и поддержки решает DevOps. Эту аббревиатуру часто употребляют в виде конкретного человека, который помогает создавать тестовые окружения для разработки, выстраивает CI\CD пайплайны и быстро выводит протестированный код в продакшн. DevOps — подход к разработке ПО, когда все участники процесса плотно взаимодействуют друг с другом и помогают быстрее создавать и обновлять программные продукты и услуги. Я имею в виду аналитиков, разработчиков, тестировщиков и поддержку.
Поддержка и разработка в таком подходе не разные отделы со своими целями и задачами. Разработка вовлечена в эксплуатацию и наоборот. Знаменитая фраза распределенных коллективов: «Проблема не на моей стороне» уже не так часто мелькает в чатах, и конечные пользователи становятся капельку счастливее.
Мониторинг
Техподдержка не ждет пока прилетит заявка с содержанием «
Как быть с ситуацией, когда остатки товаров интернет-магазина перестали приходить из ERP системы? Или CRM система, которая рассчитывает скидки для клиентов перестала отвечать? Сайт-то при этом с виду работает. Условный Zabbix получает свой 200 ответ. Дежурная смена не получила никаких уведомлений от мониторинга и радостно досматривает первую серию нового сезона «Игры престолов».
Часто мониторинг ограничивается только измерением состояния памяти, оперативки и нагрузкой процессоров серверов. Но для бизнеса гораздо важнее получить доступность товара на сайте. Условное падение одной виртуальной машины в кластере приведет к тому, что трафик перестанет на него идти и возрастет нагрузка на другие сервера. Деньги компания не потеряет.
Поэтому помимо мониторинга технических параметров операционных систем на серверах нужно настраивать бизнес-метрики. Метрики, которые напрямую влияют на деньги. Различные взаимодействия с внешними системами ( CRM,ERP и прочие). Количество заказов за определенный промежуток времени. Успешные или не успешные авторизации клиентов и другие метрики.
Взаимодействие с внешними системами
Любой сайт или мобильное приложение с годовым оборотом более миллиарда рублей взаимодействует с внешними системами. Начиная от вышеупомянутых CRM и ERP и заканчивая передачей данных о продажах внешней Big Data системе анализа покупок и предложения клиенту товара, который он точно купит ( на самом деле нет ). У каждой такой системы есть своя поддержка. И часто общение с этими системами вызывает боль. Особенно когда проблема глобальная и нужно анализировать её в разных системах.
Какие-то системы дают телефон или telegram своих админов. Где-то нужно писать письма менеджерам или ходить в баг трекеры этих внешних систем. Даже в разрезе одной большой компании разные системы часто работают в разных системах учёта заявок. Отследить статус заявки порой становится невозможно. Ты получаешь заявку в одной условной Jira. Затем в комментарии этой первой Jira ставишь ссылку на задачу в другой Jira. Во второй Jira в заявке кто-то уже пишет комментарий, что нужно позвонить условному админу Андрею, чтобы решить вопрос. И так далее.
Оптимальный вариантом решения такой проблемы было бы создание единого пространства для общения, например в Slack. Приглашение в него всех участников процесса эксплуатации внешних систем. А так же единого трекера, чтобы не дублировать заявки. Заявки должны отслеживаться в одном месте, начиная от оповещения мониторинга до вывода решения багов в прод. Вы скажете, что это нереально и у вас так исторически сложилось, что мы работаем в одном трекере, а они в другом. Появлялись разные системы, у них были свои автономные ИТ команды. Согласен и поэтому проблему нужно решать сверху на уровне CIO или product owner.
Каждая система, с которой вы взаимодействуете должна оказывать поддержку как услугу с четким SLA на решение проблем по приоритетам. А не тогда когда у условного админа Андрея найдется для вас минуточка.
Человек- бутылочное горлышко
У каждого на проекте ( или продукте ) есть такой человек, уход в отпуск которого вызывает у начальства судороги? Это может быть devops инженер, аналитик или разработчик. Ведь только devops инженер знает, на каких серверах установлены какие контейнеры, как перезагрузить контейнер в случае проблемы да и вообще любая сложная проблема без него не решается. Аналитик — единственный знает как работает ваш сложный механизм. Какие потоки данных куда идут. При каких параметрах запросов в какие сервисы, какие мы будем получать ответы.
Кто быстро поймет почему в логах ошибки и оперативно пофиксит критичный баг в проде? Конечно тот самый разработчик. Есть и другие, но почему-то только он понимает как устроены разные модули системы.
Корнем этой проблемы является отсутствие документации. Ведь если бы все сервисы вашей системы были бы описаны, то можно было бы разобраться с проблемой и без аналитика. Если бы devops выделил из своего плотного графика пару дней и описал бы все сервера, службы и инструкции по решению типовых проблем, то проблему в его отсутствии можно было бы решить и без него. Не нужно в отпуске быстро допивать своё пиво на пляже и искать wi-fi для решения проблемы.
Компетенция и ответственность сотрудников поддержки
На крупных проектах компании не скупятся на зарплату разработчикам. Хантят дорогих мидлов или сеньёров с аналогичных проектов. С поддержкой ситуация немного иная. Эти расходы всячески пытаются сократить. Компании нанимают недорогих вчерашних эникейщиков и смело идут в бой. Такая стратегия возможна, если речь идет сайте-визитке какого-нибудь завода в Зеленограде.
Если речь идёт о крупном интернет-магазине, то каждый час простоя стоит больше чем месячная зарплата админа-эникейщика. Возьмем за отправную точку 1 миллиард рублей годового оборота. Это минимальный оборот любого интернет-магазина из рейтинга ТОП-100 за 2018 год. Разделим эту сумму на количество часов в году и получим более 100 000 рублей чистых потерь. А если не считать ночные часы, то можно смело увеличивать сумму в два раза.
Но деньги ведь не главное, да? (нет, конечно главное) Есть еще репутационные потери. Час падения известного интернет-магазина может вызвать как волну отзывов в социальных сетях, так и публикации в тематических СМИ. А разговоры друзей на кухне в стиле «Не покупай там ничего, у них сайт постоянно не работает» вообще не поддаются измерениям.
Теперь к ответственности. В моей практике был случай, когда дежурный администратор не среагировал вовремя на оповещение системы мониторинга о недоступности сайта. В приятный летний пятничный вечер и сайт одного известного в Москве интернет-магазина тихо лежал. В субботу утром продакт этого сайта не понял почему сайт не открывается, а в чатах поддержки и срочных оповещений в Slack тишина. Такая ошибка стоила нам шестизначной суммы, а этому дежурному работы.
Ответственность — навык который трудно развить. Он или есть у человека или нет. Поэтому на собеседованиях я стараюсь выявить её наличие разными вопросами, которые косвенно показывают привык ли человек брать ответственность на себя. Если человек отвечает, что выбрал ВУЗ, потому что так сказали родители или меняет работу из-за того, что жена сказала, что он мало получает, то с такими людьми лучше не связываться.
Взаимодействие с командой разработки
Когда на продуктиве в процессе эксплуатации у пользователей возникают несложные проблемы, то поддержка решает их своими силами. Пытается воспроизвести проблему, анализирует логи и так далее. Но что делать когда на проде всплыл баг? В этом случае поддержка заводит задачу на разработчиков и вот тут начинается самое интересное.
Разработчики постоянно перегружены. Они занимаются созданием новых фич. Фиксить баги с прода занятие скажем не самое интересное. Горят сроки для завершения очередного спринта. А тут приходят неприятные люди из поддержки и говорят: «Срочно бросай всё, у нас проблемы». Приоритет таких задач минимальный. Особенно когда проблема не самая критичная и основной функционал сайта работает, и когда релиз-менеджер не бегает с выпученными глазами и не пишет: «Срочно внести эту задачу в ближайший релиз или хотфикс».
Задачи с обычным или низким приоритетом переходят из релиза в релиз. На вопрос «Когда задача будет выполнена?» ты будешь получать ответы в стиле: «Прости, сейчас много задач, спроси у тим лидов или релиз менеджера».
Проблемы на продуктиве имеют больший приоритет, чем создание новых фичей. Плохие отзывы не заставят себя ждать, если пользователи будут постоянно натыкаться на баги. Испорченную репутацию восстанавливать трудно.
Вопросы взаимодействия разработки и поддержки решает DevOps. Эту аббревиатуру часто употребляют в виде конкретного человека, который помогает создавать тестовые окружения для разработки, выстраивает CI\CD пайплайны и быстро выводит протестированный код в продакшн. DevOps — подход к разработке ПО, когда все участники процесса плотно взаимодействуют друг с другом и помогают быстрее создавать и обновлять программные продукты и услуги. Я имею в виду аналитиков, разработчиков, тестировщиков и поддержку.
Поддержка и разработка в таком подходе не разные отделы со своими целями и задачами. Разработка вовлечена в эксплуатацию и наоборот. Знаменитая фраза распределенных коллективов: «Проблема не на моей стороне» уже не так часто мелькает в чатах, и конечные пользователи становятся капельку счастливее.
Комментарии (14)
zirby Автор
04.05.2019 21:14Спасибо за Ваше интересное мнение. Может быть я привёл не самые удачные примеры. Но они косвенно показывают, что в переломные моменты времени жизни человека он не сам принял решение, а переложил ответственность на других. В данном случае жену и родителей.
Днем — потому что надо, ночью — потому что интересно и могу сделать лучше. Большинство моих коллег постоянно сливаются и делают задачи как из под палки. А мне наоборот интересно.
Эти поступки характеризуют Вас как хорошего человека. Вам интересно развиваться и разрабатывать софт. Вероятно, это и мотивировало. О сроках поставленных бизнесом вы не написали не слова. Часто доводилось сдвигать сроки из-за того, что хотелось сделать лучше или просто не успевали? Вот это мне кажется уже ближе к ответственности.
Вчера сам решил перетащить виртуалку с прод сервером из облака с работы, где я уже даже не работаю, к себе на сервер, потому что бухгалтер провафлил оплату хостинга на праздники, и до 6 числа случится факап. А я за ними всё равно приглядываю
Это определенно характеризует Вас как ответственного человека. Но хотелось бы понять как узнали про то что бухгалтер провафлил оплату? Попросили помочь? Либо хостинг до сих пор оформлен на Вас и Вы получаете уведомления в случае не оплаты. Тогда это опять скорее подходит под определение порядочного человека, который помогает когда его просят. Либо чувствуете вину, что так и не передали до конца продуктив на новую поддержку и поэтому сами решаете проблемы.
morozovsk
05.05.2019 01:57Если человек отвечает, что выбрал ВУЗ, потому что так сказали родители или меняет работу из-за того, что жена сказала, что он мало получает, то с такими людьми лучше не связываться.
У нас у половины страны родители выбирали университет для своих детей, потому что у детей часто нету права голоса, а родители заинтересованы, чтобы сын в армию не пошёл и выбирают ни туда куда ты хочешь, а туда куда ты скорее всего сможешь поступить, туда где есть военная кафедра и тебя не отчислят на первом курсе. Так вы теперь предлагаете половину страны сразу в утиль списать? В моём случае мне повезло и как раз хотел туда, куда родители выбрали.
Но они косвенно показывают, что в переломные моменты времени жизни человека он не сам принял решение, а переложил ответственность на других. В данном случае жену и родителей.
Я всё больше в последнее время склоняюсь, что в жизни мало зависит от того какое ты принял решение, а всё больше от воли случая.
Я, например, работал сисадмином и не искал работы программистом, потому что не умел программировать, но чисто случайно мой бывший однокурсник сказал, что у него на работе берут без знания программирования и сами всему учат. До этого момента я даже не знал, что бывают такие компании. Я жил в Ростове-на-Дону и само по себе, что в те годы та были нужны программисты — это уже было чудо.
Также я не принимал решение переезда из Ростова в Москву. Мой отец постоянно капал мне на мозг, что туда надо ехать, что не надо сидеть в Ростове. Я сдался и поехал туда в отпуск на неделю и чисто случайно нашёл работу с очень хорошей зп и я им подошёл несмотря на то что у меня было опыта работы меньше года.
Приблизительно по такой же схеме я переехал в Питер, а потом и на Кипр.
При этом всё что я делаю на работе, я никогда не перекладываю ответственность на других, более того всегда брал на себя ответственность за целое направление работ. По-этому я бы на вашем месте не делал выводов о том насколько человек будет себя вести ответственно на работе, основываясь на том что «в переломные моменты времени жизни человека он не сам принял решение».
Так что здесь нет не то что никакой причинно-следственной связи, более того как вам выше уже написали, тут даже корреляции нету.zirby Автор
05.05.2019 09:57Я всё больше в последнее время склоняюсь, что в жизни мало зависит от того какое ты принял решение, а всё больше от воли случая.
Случай и связи порой важны не меньше, чем талант и образование.
По-этому я бы на вашем месте не делал выводов о том насколько человек будет себя вести ответственно на работе, основываясь на том что «в переломные моменты времени жизни человека он не сам принял решение».
Вы уже не первый кто не согласен с этим убеждением. Спасибо Хабру, что можно получить конструктивную обратную связь и адекватно посмотреть на свои взгляды со стороны и скорректировать их.
nrgian
05.05.2019 12:52У нас у половины страны родители выбирали университет для своих детей
А если так:
«Выбрал кем хочу стать осознано, профессия нравится, работаю с удовольствием» vs «Поступил лишь бы поступить, работаю вообще по другой профессии, зря занимал чужое место в ВУЗе»morozovsk
05.05.2019 14:31зря занимал чужое место в ВУЗе
Хороший наброс. Оно не было чужим. Оно было свободным.
С таким подходом можно сказать, что человек занимает чужое место если:
- на хабре пишет комментарии, но не пишет статьи
- играет в свободное время, а не занимается самообучением
- просто обычный человек, а не Энштейн
Это можно продолжать до бесконечности. Затронутая вами тема — весьма холиварная, поэтому предлагаю остановиться. Можете просто загуглить какие-нибудь философские рассуждения на эту тему. Эта статья — про другое.
Marwin
04.05.2019 21:47Часто доводилось сдвигать сроки из-за того, что хотелось сделать лучше или просто не успевали? Вот это мне кажется уже ближе к ответственности.
В большинстве случаев мне удается выдавать заказчику пессимистично-аргументированные планы выполнения задач, довольно близкие по длительности к реальным в итоге. Поэтому не успеваю редко )) А может просто везёт не сталкиваться с бизнесом, которому надо "вчера", что бы ты ни говорил, что на это надо месяц. И считаю, что лучше потратить силы на убеждение и составление аргументов "почему на это надо месяц" ДО начала работ, чтобы потом не оправдываться.
Но хотелось бы понять как вы узнали про то что бухгалтер провафлил оплату? Вас попросили помочь? Либо хостинг до сих пор оформлен на Вас и вы получаете уведомления в случае не оплаты.
Я ушел от них просто потому что у них закончились деньги на содержание фултайм сисадмина. Но "по дружбе" их балансы у меня в мониторинге (хвала апишке Селектела). И я безвозмездно слежу за написанным мной софтом на тех серверах, ибо верю, что они смогут выйти из полуспячки и найти новых клиентов (сейчас веб порталы работают в режиме демо версий и поддержки контента для старых пользователей, поэтому особо не напрягают)
limassolsk
05.05.2019 02:35+1Статью надо было назвать «5 проблем в компании, которая ели держится на плаву».
«Человек — бутылочное горлышко»
Если в компании всё хорошо с деньгами и становится только лучше, то сисадминов обычно несколько. Более того задублированы все люди, без которых всё может встать колом.
Мониторинг
Нет менеджера отвечающего за риски, поэтому нет и метрик, чтобы следить, что на проекте всё работает как часы. В компании либо нет на него денег, либо нет понимания, что нужен этот человек.
Компетенция и ответственность сотрудников поддержки
Та же проблема — нет денег, чтобы задублировать его функции ещё одним человеком.
Взаимодействие с командой разработки
Здесь вообще непонятно почему вы подходите и дёргаете разработчика отвлекая его от работы. Либо сами смотрите в жире статус вашей таски и в какой спринт она попадёт, либо идёте к тимлиду, о чём вам собственно и сказал разработчик, но вы почему-то всё равно считаете, что это неправильно и именно разработчик должен дать вам объяснение почему ваша таска не попадёт в этот спринт. Когда тебя за день дёргает большое количество людей по поводу статуса задачи, которой у тебя даже в спринте нет, то возникает желание убивать всех вокруг людей с такими вопросами. Поэтому первые один-два раз вежливо объясняешь, что это лучше уточнить у тог, кто планирует задачи. Если человеку двух раз не хватило, то сообщаешь об этом менеджеру, чтобы он провёл разъяснительные работы.
Если в компании нет денег или на всём экономят или нет грамотных процессов внутри компании, то проблем там гораздо больше чем 5 и их количество будет только расти.zirby Автор
05.05.2019 09:49Статью надо было назвать «5 проблем в компании, которая ели держится на плаву».
К сожалению такая картина встречается и в довольно крупных компаниях, уверенно стоящих на ногах.
Если в компании всё хорошо с деньгами и становится только лучше, то сисадминов обычно несколько. Более того задублированы все люди, без которых всё может встать колом.
Часто когда в компании несколько админов, то каждый из них эксперт в конкретной области и они скорее не распараллеливают друг друга, а дополняют. А их руководитель по-умолчанию должен знать всё. Но это не всегда так.
Здесь вообще непонятно почему вы подходите и дёргаете разработчика отвлекая его от работы
Полностью согласен. В правильно выстроенных процессах такое общение вообще сводится на нет и всю информацию можно получить из Jira. И критичный приоритет заведенной задачи с меткой prod сразу приводит к тому, что её выполняют в кратчайшие сроки. Но на моей практике часто бывает иначе.
Если в компании нет денег или на всём экономят или нет грамотных процессов внутри компании, то проблем там гораздо больше чем 5 и их количество будет только расти.
Да проблем и правда больше. Тут скорее про процессы, чем про деньги. Когда компания еле держится на плаву, то обычно один единственный разработчик занимается и разработкой и поддержкой и мониторингом, как в случае с Mawrin в соседней ветке комментариев.
sn00p
05.05.2019 13:33+1Проблем с процессами нет, есть проблема с IT директором или его отсутствием.
Придумали уже кучу софта и best practises, а также довольно давно существует здравый смысл.
дежурный администратор не среагировал вовремя на оповещение системы мониторинга о недоступности сайта
Кто мешает настроить электробабу, которая в случае такого начнет звонить всем по цепочке вплоть до генерального директора? Нагибос появился двадцать лет назад, там уже был механизм acknowledge. В Заббиксе подобное тоже есть. Бота в слаке для подобных случаев написать тоже не проблема. Миллион вариантов это решить.
Более того. Если человек проблему забрал и не может решить, алерт рано или поздно разгорится до критикала и снова привет, электробаба.
Про баги на проде я вообще не понял. В нормальных конторах это всегда наивысший приоритет. Если где-то бывает иначе, надо бежать из таких заведений куда подальше. Я таких контор уже лет 15 не видел.
Marwin
Я именно такой по обоим пунктам. Но сие предположение меня огорчает. Всю свою 15 летнюю программерскую жизнь я вёл в режиме работы днем и ночью без праздников и выходных. Днем — потому что надо, ночью — потому что интересно и могу сделать лучше. Большинство моих коллег постоянно сливаются и делают задачи как из под палки. А мне наоборот интересно. Даже сейчас на праздниках я сижу и работаю на перспективу, портирую часть платформы на новый стэк, ибо есть шанс, что новый клиент её закажет, и там это понадобится. Вчера сам решил перетащить виртуалку с прод сервером из облака с работы, где я уже даже не работаю, к себе на сервер, потому что бухгалтер провафлил оплату хостинга на праздники, и до 6 числа случится факап. А я за ними всё равно приглядываю… ибо ну хорошие же ребята, просто невезет им.
Или мы говорим о какой-то разной ответственности?
nrgian
Работать по ночам — это скорее безответственность.
Снижается же производительность труда днем.
Marwin
ну это скорее утрированное понятие. Естественно, я не сижу до 4 утра каждый день в ущерб сну. Но всегда есть пара часов вечером, которые большинство тратит на втыкание в телек или семейные дела (понятно, что этот момент важнее работы, но у меня вот так...), а я возвращаюсь к коду, ибо это и дает мне моральный отдых после дневного спринта обязательных задач