Ноя
11

ВременнЫе проблемы




  • Утечка

  • Где водятся волшебники или “Солнышко, подвези до угла”!


  • Нет, я всё-таки не понимаю, совсем не понимаю: для чьей конкретно пользы мы дважды в год переводим стрелки? Что мы хотим сэкономить? Где можно взглянуть на расчёты, подтверждающие экономическую целесообразность такой неудобной вещи, как «летнее время»?

    И как в этих расчётах учтены экономические потери, вызванные человеческими ошибками, связанными с таким мощным источником возмущений? Может быть, в эпоху свечей и лампочек Эдисона какая-то выгода и просматривалась (хотя…), но мы сейчас живём в мире, насыщенном компьютерами и автоматизированными системами. В которых скачки времени на час вперёд или назад могут порой вызывать странные эффекты. Кто-нибудь пробовал подсчитать, чего стоит программистам и системщикам обеспечивать корректную работу приложений и, что гораздо сложнее/важнее, -- корректное взаимодействие между приложениями?

    У свечей нет встроенного таймера. Но свечи уже не актуальны. А у того, что актуально, таймер есть.

    Errare humanum est. Человеку свойственно ошибаться. И чем сложнее у человека задача, тем выше вероятность ошибки. Талантливый руководитель всегда помнит об этом, поэтому всегда стремится снизить сложность задач, выдаваемых персоналу. Чем проще – тем больше шансов на общий успех. Плохой руководитель гонится за бОльшим успехом, забывая о попутном увеличении рисков. И садится в лужу. Но виноватым оказывается, конечно, не он, а исполнитель, допустивший ошибку. Ошибку, риск возникновения которой мог, но не захотел, снизить руководитель.

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

    Свежий пример (из-за чего и взялся писать, собственно). Авария автоматизированной системы, СУБД разрушена, нужно её восстанавливать из бэкапа. Персонал, выполняющий восстановление, должен решить: до какого момента времени нужно восстанавливать транзакции? Посмотрели на метку времени последней транзакции в приложении, и аккуратно выполнили восстановление по ней. Запустили систему. Та, довольно урча, начала работать.

    Спустя некоторое время выяснилось, что транзакции за последний час работы системы пропали. Оказалось, что СУБД жила по летнему московскому времени (GMT+4). А сервер приложений – по простому московскому (GMT+3). Ну не настроен он был на учёт переходов (либо невозможно его в принципе настроить, такое тоже бывает). В результате, один час работы системы не был восстановлен, что являет собой довольно эпичную картину.

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

    Летнее время – зло. Беречь нужно людей, а не киловатты.




  • Утечка

  • Где водятся волшебники или “Солнышко, подвези до угла”!



  • Социальные сети

    Рубрики

    Последние записи