Комментарии 74
Может тут больше приоритет подойдёт, а не срочность? Прилетела идея, её оценили и сочли важной
Кто то «профакапил» и не правильно просчитал спрос? Да нет, это в ряде случаев просто не возможно для новых продуктов.
я таки думаю, что для этого придуманы маркетологи. и хороший маркетолог стОит своих денег
Ну или, не знаю, поломалась что-нибудь дорогое, какая-нибудь кофе-машина. Чайник — материал расходный, ему можно купить резерв: сгорел — заменил на запасной, едем дальше. Но далеко не всё получается IRL дублировать.
На чей счёт заносить поломки оборудования, которые выливаются в срочную работу? Достаточно часто такое бывало — никакой мониторинг не предвещает, просто в один прекрасный день некое устройство выключается, и больше не включается.
Вот же ответ:
Сисадмин подавал заявку на резервный сервер, а ИТ-директор не подписал? Виноват ИТ-директор, он — причина срочности. Не оплатил финдир, потому что из бюджета выбились? Виноват ИТ-директор, который криво ведет бюджет. Директор компании запретил покупать «всю эту чушь для айтишников»? Виноват он.
Попробую немного развернуть. Когда руководитель умный, он в обязательном порядке учитывает возможность внезапного выхода из строя оборудования. ОБЯЗАТЕЛЬНО! Соответственно, у такого умного руководителя просчитано, сколько стоит резервирование ресурсов (неважно, оборудования, сырья, кадров, а кадры, особенно квалифицированные — это таки для компании тоже ресурс! и т.д., и т.п.), и сколько стоит простой на время ремонта, сам ремонт, ну и вот это вот всё. Поэтому у такого руководителя оборудование выходит из строя редко, люди не сваливают в туман неожиданно, и вообще, трудиться в подобных компаниях — весьма полезно для психического здоровья. А реальные внезапные сбои, которые таки случаются в обязательном порядке — они просто решаются. Без истерик и прочих недовольствий.
Вышел из строя сервер. Есть резервное «железо», бери, ставь и запускай. Но «ставь и запускай» в такой ситуации — задача всё равно срочная. Пусть даже всё сто раз просчитано и всё выделено — срочности никто не отменяет.
Или предполагается ещё и специальную должность выделить — человек, который в штатных ситуациях вообще ничего не делает, зато в таких вот выполняет работу, на которую не отвлекут никого другого?
Что, повторюсь, IRL нереально. Скорее я поверю, что есть «пустые» готовые железяки, на которые можно быстро восстановить состояние того, что квакнулось.
UPD: Бывают отдельные случаи когда невозможно или слишком дорого, но обобщать абсолютно неправильно. И да, автоматизация была проведена после ручной починки предыдущей аварии. Первая авария исправлялась два часа. Автоматизация заняла два месяца. Вторая авария была исправлена за несколько минут.
Нереально не восстанавливать в реальном времени — речь не об этом.
Нереально держать для каждого устройства резервную копию, годную для немедленной замены. Возможно, это идеальное состояние, но IRL такого, похоже, просто не бывает. Если есть примеры — в студию, с подробностями.
Вы меня таки извините, но приведите, пожалуйста, конкретные примеры компаний, где НЕТ резервирования по ресурсам. А то вот я имею опыт эксплуатации вычтеха в промышленности, торговле, интернетах (интернет-компании и операторы связи), и вот это вот всё — и как-то не могу вспомнить, чтобы критичные к простоям ресурсы не резервировались (вернее, такое было, но в начале 2000-х). Сейчас резервируется всё, в режиме от ручного переключения (несколько минут простоя) до автоматического (так, что пользователь сервиса ничего не замечал).
в режиме от ручного переключения (несколько минут простоя)
Вот вам и срочная задача, пусть даже на несколько минут.
Дело в том, что я рассматриваю всю статью, и, соответственно, круг задач, которые в этой статье описываются, не просто как срочные, а из тех, которые: никогда не было, и вот опять! (с)
Т.е. работало, работало, а тут — бац, и не работает, применительно к эксплуатации. И никто не знает, что делать, куда бечь, кого искать, ну и вот это вот всё.
В описанной же мной ситуации с ручным переключением, выход сервера из строя — это ШТАТНАЯ ситуация с вполне определёнными и описанными действиями в случае её возникновения. Т.е. никто не кричит, не бегает, волосы из тела не вырывает, а просто ответственный выполняет нужные, описанные в соответствующем регламенте манипуляции.
Мало того! В подобных ситуациях ПЕРЕД тем, как приступить к устранению проблем, этот ответственный направляет соответствующее письмо в определённый список рассылки! О как!
Вот когда простой начинает выходить за определённые временные рамки, вот тогда да — начинается цирк. А так… Никакой срочности не вижу.
Вы утверждаете, что в нормальной компании всё 100% дублировано / зарезервировано — вам и примеры приводить.
(хотя не очень понимаю, как их приводить — вряд ли сотрудникам компании позволено трепаться в Сети, как там у них что устроено)
А зайду-ка я с тузов. Козырных.
вам и примеры приводить.
гугель, яндекс, мейл.ру. В Сети материалов, как оно у них всё устроено — вагон и маленькая тележка.
Есть такая конференция: pgconf. Так вот на ней далеко не один доклад, где рассматривается обеспечение отказоустойчивости постгреса в конкретных компаниях. Вот, например, газпром:
https://pgconf.ru/media/2020/02/17/Operating_experience_of_PostgreSQL_servers_in_a_corporate_network.pdf
Было бы странно, если бы у всехэтих заоблачных сервисов всё не было бы дублировано по сто раз.
Вот когда я видел помещение, где один из наших провайдеров держит сетевое оборудование (в здании, где компания находится) — там 100% вообще ничего не дублировано и не зарезервировано.
Рискну предположить, что так же у большинства, хотя в большинстве исторических ситуаций связность чинилась очень быстро, невзирая на.
У вас есть данные, сколько компаний действительно готовы потратить минимум усилий на восстановление своих сервисов, поскольку всё дублировано, реплицировано и т.д. и т.п.?
Приводить в качестве примера гигантов индустрии как минимум смешно — эти могут себе позволить продублировать всё несколько десятков раз.
А если взять произвольную компанию, не из гигантов — там как дела обстоят? Есть сведения?
Судя по тому, что я наблюдаю в ближайшем окружении, нет повального дублирования всего и вся. Обычно находят некий компромисс между возможностью действительно всё продублировать и возможностью минимизации времени на устранение неполадок.
Вот такая статистика была бы интересна, а не данные по Google, Microsoft и прочим крупнейшим компаниям.
Я бы очень бы хотел посмотреть на ту компанию, у которой есть пара дисковых «накопителей» любого вида на десяток-другой петабайт штука, один из которых резервный и полностью дублирует основной.
То, что вижу я.
- Местные провайдеры сжираются федеральными операторами связи. Именно потому что крупняк всё резервирует, причём не просто дублирует, а МНОГОКРАТНО резервирует ресурсы. Включая кадры. А мелочёвка — у них а) денеХ нет; б) оне жадные;
- крупные торговые сети — многократное резервирование (на собесах бывал неоднократно);
- газпром я привёл;
- промышленность, судя по требованиям — резервирование ресурсов — во все поля.
Остаются мелкие мастерские и магазинчики. Вот там, где я живу, мелкие магазинчики, ВСЕ!, вообще ничего не ведут в компах. Бухучёт — на бумаге, представьте себе! в 2020-м году. Такие дела.
У нас зоопарк VM, с разными ОС и сервисами на них. Далеко не все они БД, и далеко не всегда возможна репликация состояния в реальном времени.
UPD: «У нас зоопарк» не аргумент изначальному «нигде и никому невозможно обеспечить отказоустойчивость»
Вопрос не в том, чтобы всё воскресало в реальном времени, а чтобы за разумное время. И да, это время уже примерно известно (в т.ч. по итогам реальных инцидентов), и на него ориентируемся.
По счастью, действительно внезапных и катастрофических падений было крайне мало — признаки того, что ту или иную железку пора менять обычно заметны задолго до.
Ну или, не знаю, поломалась что-нибудь дорогое, какая-нибудь кофе-машина.если кофе-машина напрямую важна для бизнеса, то надо (по-хорошему) держать в резерве машину попроще. если нет — то срочно её чинить не надо (у нормальных людей).
"27. Я не стану создавать что-либо, действительно важное, в единственном экземпляре. У всех важных систем будут дублирующие пульты управления и резервные источники энергии. По той же причине при себе у меня всегда будет два полностью заряженных экземпляра оружия."
По мне, ситуация фактически нереальная, когда действительно дублируется всё, что влияет на бизнес-процессы (так, чтобы решалось действием вида «достали из коробки и поставили на место»).
А что у нас говорят законы Мэрфи, т.е. народная мудрость?
«Не спеши выполнять приказ — его могут отменить».
«Если отложить дело надолго, то его либо выполнит кто-нибудь другой, либо оно вообще перестанет быть нужным».
Если эти два пункта не прошли — то да, дело становится срочным.
Если срочную задачу принесли вам, спросите реальный срок ее возникновения. Этим вы поможете, в первую очередь, тому, кто принёс задачу.
О, я смотрю, nmivan уже забыл как оно в реальной жизни на самом деле. Это когда ты программист, царь рынка труда, можно начальника лицом в его же ссанину тыкнуть. А в реальной жизни это сразу война, можно искать новую работу.
И вообще: менеджер нужен для обслуживания программиста. Он — помогайка, секретарша для неважных вопросов, вроде расстановки приоритетов, контроля сроков, кофе, чая и т.д.
Мне кажется, такую реальность для себя можно и нужно создавать.
А мне вот не кажется. Я — ЗНАЮ, что эту реальность надо создавать. ;)
И что никто, кроме самого индивидуума, эту реальность для него за него не создаст. Банально, но факт: каждый сам кузнец своего счастья.
Но это надо трудиться:
- совершенствоваться в своей специальности, чтобы заслужить уважение коллег, включая того же начальника;
- смотреть вокруг, как минимум, на смежные специализации, запасной парашют — это не только и не столько счёт в банке, сколько возможность манёвра своими знаниями и умениями на рынке труда;
- ну и много другого разного, чего человек вообще-то обязан сам с собой делать. Иначе это необходимое для него за него и с ним будут делать другие. С немножко прогнозируемым результатом.
И кто то ЗНАЕТ что ему это совсем не нужно. А нужно получать свою порцию адреналина от стрессовой ситуации. Например.
Звучит прямо как слабоумие и отвага.
Да какие тут оскорбления, просто метафора очень уж в кассу пришлась.
По правде говоря, эта фраза не столько про "героя" (т.е. того кто спас положение), сколько про его руководство. Или про ситуацию в целом. А для "героя" подобная ситуация, с точки зрения его карьеры — только на пользу. Ведь это — лишнее достижение, за которую премию дадут. Или станет ярким пунктом годового ревью и основанием для повышения. Или даже отличной строчкой в резюме.
С точки зрения же бизнеса как процесса, ситуаций, которые требуют "героизма" всё же лучше избегать. Ведь они увеличивают неопределенность, что ведёт к убыткам.
Я вот сколько вкалываю, но не помню, чтобы уточнение сроков решения задачи воспринималось как
начальника лицом в его же ссанину тыкнуть.
независимо от уровня руководителя. Т.е. от слова совсем. Почему-то все руководители к подобным уточнениям относятся нормально. Может потому, что я на берегу (во время собеседования) и этот вопрос затрагиваю: когда сроки в трекере не определены, я прошу уточнить эти сроки.
когда сроки в трекере не определены, я прошу уточнить эти сроки.
Насколько я понимаю, речь не о том, а именно о «спросите реальный срок ее возникновения» (выделение моё). Т.е. Вам менеджер принёс срочную задачу, а Вы его спрашиваете что-то вроде: «Суфир, а вот скажи мне, это разве не та задача, которую ещё месяц назад на митинге озвучивали, а потом я ещё напоминал неделю назад, что мне на неё ресурсы выделить нужно?».
Среднему программисту за такое ничего не будет, а, например, мою маму — медсестру в пост-советской больнице — за такую наглость на ноль помножили бы (о чём Mabusius и написал).
Спасибо, что ткнули меня в мою невнимательность.
Среднему программисту за такое ничего не будет
Вот насчёт среднему — я не уверен. Несмотря на постоянные жалобы от руководителей различного уровня об отсутствии кадров.
Другое дело, что я невнимательно, каюсь, прочитал исходное сообщение. Что не отменяет необходимости вкалывать, чтобы иметь возможность задавать руководителям подобные вопросы.
Именно для разрабов/эксплуататоров частичным решением подобных неувязок (когда управленец забивает на инициативы сотрудников) являются следующие меры:
- основное: собственно, я выше писал — на собесе указывать о необходимости реакции на свои инициативы; почему основное — так предупредить пожар существенно дешевле и проще, нежели потушить; другое дело, что озвучивание подобного пожелания увеличивает сроки трудоустройства, но тут уж каждый сам себе хозяин;
- если уж вляпались, то:
- инициатива должна быть оформлена в письменном виде;
- при отсутствии своевременной реакции на инициативу или реакции негативной, потихоньку ковырять в сторону этой инициативы;
ковырять — оно да, может быть, по-разному, когда это необходимость закупки железа для резервирования мощностей, потому что сервер службы каталогов в компании один-единственный, и на него дыхнуть боятся… В такой ситуации я советовать ничего не буду. А то обвинят в звёздной болезни. :(
Когда же речь идёт о каких-то наработках, которые могут быть сделаны без лишних материальных трат, эти наработки лишними отнюдь не будут.
кто-то, где-то, что-то профакапил
Ну, далеко не всегда. Я бы даже сказала, что в большинстве случаев такие задачи — результат самодурства самого высокого руководства. Ну, типа «захотелось». Хотя, конечно, от компании зависит
Срочное — имеющее определенный срок (дед-лайн). А то про что статья по русски должно называться спешным.
Те словари, которые быстро-быстро находятся поиском (пишут, что Ожегова и Большой Толковый словарь русского языка), говорят, что и значение "быстро! немедленно!", и "в определённый срок" — имеют право на существование.
Но в современном русском языке «срочное» и «спешное» — синонимы, причём «спешное» явно выходит из употребления (хотя статистику предоставить я не могу).
Срочные задачи. Да придёт Спаситель