Новорічні пригоди. Розробники розповіли історії з роботи, що трапилися на зимові свята

Чи траплялися з вами у Новорічну ніч веселі або трешові історії, пов’язані з роботою? З деякими IT-фахівцями — так. Все ж, не кожного дня доводиться лізти через ворота, аби врятувати сервер і не кожного Нового року сидиш у страху, що недостатньо добре протестований софт дасть збій. А раптом якийсь курйоз стався із вами у новорічну ніч — пишіть у коментарях.

Заради порятунку сервера у новорічну ніч довелося лізти через ворота

Олександр Соловйов, CTO Kasta.ua

Нещодавно мій знайомий Саша, з яким я колись працював у «Колоколі», нагадав смішну історію. У новорічну ніч 2004 року хтось мав залишитися на роботі — в компанії ж цілодобова підтримка. За цю ніч між усіма колегами проводилися «торги», і, врешті, того дня залишилися саме ми вдвох.

Ніби ж свято, тож ми випили шампанського чи ще чогось. Сидимо собі, щось робимо. Аж раптом після 12 ночі, вже у прийдешньому році моніторинг почав сигналізувати, що якийсь з серверів на Леонтовича помер і не відповідає.

Якихось супер технологій у нас не було. Ми трохи почекали і я пішов подивитися, що там трапилося. Я — бо ми по черзі були відповідальні за майданчики колокейшена на Тургенєвській та Леонтовича. Ночі ж проводили на Тургенєвській, бо там був нормальний офіс, а на Леонтовича — страшна комірка при гермозоні.

Прийшов, а там ворота до арки зачинені. Перша година ночі, охоронець — хтозна-де. Можливо, у себе в будці й навряд чи тверезий. Я ж стою перед зачиненою аркою і намагаюся дізнатися, чи є у нас телефон того охоронця, чи можна з ним якось зв’язатися.

Телефону, звісно ж, не було. Натомість я згадав, як у давно прочитаній книзі якийсь герой запевняв, що головне — просунути в отвір голову. Якщо вдалося — то пролізеш і всім тілом. До того ж тоді я тоді важив на 20 кілограмів менше, ніж зараз, тож вирішив спробувати. Зняв куртку і таки проліз туди. Пішов дивитися на сервер. Приєднав екран, а там FreeBSD’шний демон по екрану літає. На натиски на клавіатурі не реагує — висить.

Перезавантажив його, все завелось. Моніторинг підтвердив, що все добре, і я пішов собі назад.

Чому не варто софт для пульта охоронного спостереження ставити на центр ДСО без повноцінного тестування

Сергій Марущенко, Lead Software Engineer at N-iX

У 2007 я працював над розробкою софту для пульта охоронного спостереження, який без повноцінного тестування поставили на справжній центр ДСО. Втім, без проблем таки не обійшлося.

Виявилося, що ретранслятор збирав сигнали з приладів, накопичував їх і відсилав на пульт через UDP-протокол. На кожне повідомлення його вузли чекали відповіді, що мало б свідчити про успішний прийом. Не отримавши такої за певний проміжок часу (вже не пам’ятаю який, в межах хвилини, мабуть), він генерував повторне повідомлення про ту ж саму подію.

Об’єктів було багато і це перевищувало здатність нашого пультового ПЗ обробити їх вчасно, причому не було поняття пріоритетності, «трасування» тривіальних подій проходило так само як і панічна тривога, тому що ранжування за важливістю було прерогативою вже самого пульту.

От і виходило, що єдиним адекватним засобом для того, щоб «заспокоїти» систему, було під’єднатися замість пульта через ту консоль (то був не командний рядок, а десктопна аплікація, консоллю це назвав хтось з інженерів, я казав «Отладчик» ), оскільки вона відпрацьовувала згідно з протоколом, але нічого не зберігала інакше як виводом на екран.

Після того як більшість сповіщень були опрацьовані, можна було під’єднати пульт назад.
Очевидно, що в той момент об’єкти були беззахисні. Нічого з ними не сталося насправді потім ми усунули ті проблеми, але, щоб «мотивувати», техдиректор видав страшилку — ви, каже, думаєте, «генеральний» буде платити зі своєї кишені компенсацію, якщо когось пограбують? Він повісить усі збитки на вас! Ууууу!

Все це сталося у листопаді. А під Новий рік 2008 ситуація повторилася: чи то внаслідок знеструмлення, чи-то перебоїв зі зв’язком.

Я святкував Новий рік із батьками, і ми все ще боялися: «Раптом від феєрверків почнуться хибні спрацювання охоронних датчиків (зокрема датчиків розбиття скла) і мені доведеться знову чаклувати з консоллю?»

До речі, маленька технічна довідка: тодішній охоронний пристрій не такий вже й складний. Він контролює опір ряду (2, 4, 8) контурів-«шлейфів», на кожен з яких послідовно підключаються один чи кілька датчиків, конфігурація яких вноситься у базу даних на пульті. У випадку спрацювання змінюється опір контуру, викликаючи сигнал, приміром, датчика розбиття скла чи тривожної кнопки. Можна конфігурувати й так, що спрацювання дасть лише інформаційне сповіщення, не кажучи вже про те, що для контролю шлейф має бути «встановлений під охорону».

Головне те, що ця ситуація показала всім сторонам: нам необхідне інтеграційне тестування. Тому був виділений ретранслятор і ряд охоронних пристроїв, з якими ми намагалися імітувати реальну ситуацію. А до того наше тестування обмежувалося одним-двома пристроями на одному ретрансляторі (це при тому, що пульт підтримував ще й інші канали, зокрема мобільний CSD та звичайну виділену телефонну лінію).

Тобто, перш за все, я зробив усе, що було можливо, щоб підвищити швидкість і надійність системи, а вже далі, завдяки цьому тестувальному стенду, вже можна було отримати зворотний зв’язок без «тестування в продакшні».