DevOps на on-call 24/7: коли пейджер замінив особисте життя

frontend_burnout

"Усі так роблять" — улюблена мантра менеджерів замість відповіді. Класика. Ще краще коли кажуть що ти «частина сім'ї» — типу в сім'ї ж не рахують хто скільки посуду помив, правда?

diMaster_60

Молодий чоловік, я ще пам'ятаю часи коли взагалі не було ніяких «пейджерів» — чергування на підприємстві означало фізично сидіти в серверній. Але навіть тоді це оплачувалось окремим рядком у розрахунковому листі. Стаття 107 КЗпП України — оплата роботи у надурочний час не менше подвійного розміру. Стаття 108 — робота у святкові та неробочі дні. Усний договір — це взагалі не договір, шановні. Я б рекомендував все офіційно оформлювати, а не на словах. Бо «так прийнято» — це не норма права.

remote_zarobitchanin

Тут є кілька важливих нюансів залежно від того як ти оформлений. Якщо ФОП — КЗпП фактично не застосовується, є тільки контракт. Якщо найманий працівник за трудовим договором — так, КЗпП на твоєму боці. В Польщі, наприклад, у IT-контрактах B2B окремо прописується «dyżur» (черговість) з фіксованою ставкою за годину доступності, плюс окремо за кожен реальний виклик. Нічого екзотичного — просто нормальна contractual практика. Якщо «Девхаб» аутсорс і має іноземних клієнтів — вони самі вимагають SLA. SLA є, а компенсації за виконання SLA немає. Це треба фіксувати письмово і підіймати питання офіційно.

hr_zlo

Окей, зайду з іншого боку. Я HR і скажу чесно — більшість компаній просто не закладають on-call compensation у бюджет, бо... ніхто не питав. Серйозно. Якщо кандидат на співбесіді не питає «а як компенсується черговість?» — компанія замовчує. Не тому що злодії, а тому що так склалась традиція і ніхто не піднімав. Але якщо ти підіймаєш — це вже перформанс-розмова або юридична тема. І я б радила спочатку зробити письмовий запит до свого менеджера з конкретними цифрами — як оце ти розписав — перед тим як іти в Держпраці. Бо ескалація одразу в інспекцію = конфлікт, а конфлікт = характеристика при наступному пошуку роботи. Так, несправедливо. Але реально так.

zavod_kriviy

У нас на заводі інакший варіант тієї самої проблеми. Позмінна робота, ЧПК верстати, нічні зміни. Формально доплата за нічний час 20% від тарифної ставки — ст. 108 КЗпП. Фактично бухгалтерія раз у квартал «забуває» порахувати правильно. Я навчився: кожен місяць сам рахую таблицю — дата, зміна, нічний час (з 22:00 до 6:00), сума доплати. Порівнюю з розрахунковим листом. Розбіжність фіксую письмово. За рік назбирав три заяви до бухгалтерії — двічі доплатили мовчки, один раз довелось звертатись до профспілки. Але головне — документуй кожен інцидент. Без цього ти просто слова проти слів.

frontend_burnout

«Характеристика при наступному пошуку» лол. Тобто «мовчи або отримаєш погану характеристику» — і це ти подаєш як пораду? Нормально.

hr_zlo

Я подаю це як реальність ринку, а не як моральну норму. Різниця є. Звісно несправедливо. Але я ж теж усередині системи — і кажу як є, а не як мало б бути.

derzhsluzhbovets_ye

Дозволю собі зауваження з іншого сектору. У держслужбі ненормований робочий день прописується в контракті і теоретично дає право на додаткову відпустку — 7 календарних днів (ст. 8 Закону про відпустки). На практиці цю відпустку або не надають, або надають формально без фактичного відпочинку, оскільки справи не зупиняються. Відмінність від вашої ситуації: у нас хоча б є норма в документі. У вас, судячи з опису, немає навіть норми. Рекомендую: зафіксувати у письмовій формі умови чергування, отримати відповідь від роботодавця також у письмовій формі, і лише після цього — Держпраці або суд. Без документів будь-яке звернення малоефективне.

devops_peklo

Дякую всім за відповіді, спробую підсумувати що реально допомогло і що раджу тим хто в схожій ситуації. По-перше: фіксуйте все. У мене є git-репозиторій (так, я DevOps) де в markdown-файлі логую кожен incident із timestamp, тривалістю і короткою нотаткою. Це ваша доказова база. По-друге: перед будь-якою ескалацією — письмовий запит менеджеру з конкретними цифрами і проханням пояснити порядок компенсації. Їхня відповідь (або мовчання) — теж документ. По-третє: якщо ФОП — переглядайте контракт, on-call має бути окремим рядком. Якщо трудовий договір — ст. 92, 106, 107 КЗпП прямо стосуються вас. По-четверте: Держпраці (dsp.gov.ua) приймає анонімні скарги онлайн. Перевірки реальні, штрафи для роботодавця суттєві. І насамкінець — якщо вам на співбесіді кажуть «on-call є, але це ненапряжно», просіть показати incident log за останні 3 місяці. Якщо не показують — або немає, або соромляться. Обидва варіанти інформативні.

remote_zarobitchanin

Гарне підсумування. Додам одне: якщо компанія має іноземних клієнтів або материнську структуру за кордоном — можна також посилатись на їхні внутрішні compliance-вимоги. Часто там є правила щодо working hours і on-call compensation, які формально розповсюджуються і на підрядників. Це додатковий важіль. І так, git-лог інцидентів — це geek-рівень доказової бази, але працює.

diMaster_60

Ось бачите — коли підходити до питання системно і з документами, то і результат інший. Я б ще порадив зберігати роздруківки або скриншоти переписки з керівництвом — месенджери часом чистяться або акаунти видаляються. Паперовий слід або PDF-архів на зовнішньому носії — старомодно, але надійно. Сорок років в IT навчили одному: те що не задокументовано — не існує.