On-call зміни

Всім привіт,
прийшов і мій час звертатись до ком’юніті по допомогу :)

Справа в тому, що в моїй команді не так давно звільнили техліда, який був відповідальний за проблеми на проекті в будь-який час доби. Тепер on-call зміни хочуть поставити нам, звичайним девелоперам. Команда у нас маленька, всього три дева, один з яких — чистий фронт, тому, його ставити в зміни немає сенсу.

Я просто хочу запитати, чи був у когось подібний досвід. Який був графік змін (і скільки при цьому людей в команді)? Чи був якийсь notice period дістатись до робочого місця? Доплати, компенсації? І як виходило суміщати це «щастя» з нормальним життям та регулярними активностями в неробочий час (спорт, курси, спілкування з друзями, коли не можеш просто все кинути і бігти до компа)?

Заздалегідь дякую за поради :)

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

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

У нас було 15 хвилин, щоб відписатися що побачив і на скільке це критично. Як у вас, треба запитувати.

Компенсація — так була. Прийнято, що це фіксована сума, яка не залежить від ставки.

Тяжко це було суміщати з життям. Я їздив з ноутом завжди. Проблеми були майже кожен день. За пів року ми зменшили кількість таких проблем до одної на місяць. Але я на таке більше не підпишусь. Завжди голова забита тим, що може щось трапитись, а ти без інету.

Перш за все 3 людини — то дуже мало. Десь 4 треба, щоб один раз на місяць припадало чергування.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Карiна, як враження вiд On-call?

На щастя, тема затихла і менеджер нас більше не чіпав з пропозиціями про on-call.

Вiтаю, вам повезло.

На останнiй роботi менi довелося сапортити продукт паралельно з розробкою, були чергування on-call. Вимотало трохи, все так, як в цьому топiку.

кілька років тому я працював як l2 Support Engineer\Devops, і чесно кажучи досвід досить такий спірний. Це був старт в ІТ і так як джуна час досить дешевий, то я вважаю що воно того було не варто (тиждень онколів +50 дол і кожна затрекана година х2).
А тепер по порядку:
— Є такі поняття SLA i SLO , але вас має найбільше цікавити саме SLA — це узгоджиний час на дослідження і фікс помилок поділений за пріорітетом і чим SLA більші, тим якість вашого життя при супорті буде краща. ( У мене один із проектів мав SLA 15 хв на High priority alert який прилітав то раз в тиждень то кілька в різний час і це був неймовірний стрес, особливо якщо ще поєднювати сімейне життя та народження дитини).
— Другий ключовий фактор — це хто і як конфігурував моніторинг, оскільки коли вночі прилітає false-positive алерт і він вас будить, ви тратите короткий час на дослідження і отримаєте дуже низьку компенсацію за те що втратили міцний сон. Від якості моніторингу залежить якість вашого сервісу.
— Команда і графік чергувань — завжди є якість життєві потреби, можливі тимасові проблеми із здоровям чи просто треба піти на закупи у вихідний, тому треба призначати крім відповідального за он-колл ще й відповідального за бекап з котрим узгодити що в разі проблем ви до нього звернетесь по допоміжний сапорт або легкий бекап. В принципі -це може бути людина яка буде наступна хто заступить після вас.
— відповідальність- чітко треба проговорити відповідальність, яку ви несете в разі невкладання в SLA і розмір пенальті та штрафів, розмір компенсацій кастомеру за неналежне надання сервісу, оскільки можна продати все і лишитись винним якщо контракт прописаний не на вашу користь.

Зі свого досвіду і з досвіду колег своїх, я можу сказати, що нічого поганого нема в роботі у сапорті якщо потрібні додаткові гроші, але якщо ви задоволені рівнем теперішньої компенсації та рівнем життя то не рекомендував би підписуватись на нього, оскільки :
— ви як молода дівчина втратите особисте життя, або значно його ускладнете
— сон значно погіршиться і при пробудженні серед ночі важко буде самостійно засипати протягом кількох годин ( якщо я проснувся від будь-якого шуму, то засинаю від 1 год до 3 )
— нервозні стани, швидка дратівливість та інші проблеми із здоровям вам гарантовані якщо не зразу, то через деякий час .
— можливість попасти у гроші при невкладанню в SLA
— зменшення вільного часу на хоббі,друзів, розваги що може призвести до вигорання

техліда, який був відповідальний за проблеми на проекті в будь-який час доби

До речі, працював саме таким техлідом на достатньо великих проєктах декілька разів. І тому досі вважаю що в сучасному вигляді он-коли це костиль, ваша попередня схема мені подобається значно більше.
Як вірно пишуть фанати цього явища, он-коли були завжди в індустріі, це правда. Але ми робили (а подекуди і робимо) це по іншому, в нас були інші учасники.

Учасник 1: Адміни
Ну так, сервери іноді підвисають, місце на дисках закінчується, ключи експаряться, що ж тут поробиш, різне лайно трапляється. Тому притомні компаніі наймали адмінів-контракторів, і платили їм фіксовану зарплатню в місяць, це важливо: не за кількість інцидентів і не за кількість годин. Давали їм там пейджера, піздніше телефон, ну і так, адміни знали що іноді треба і в 3 години вночи вставати і щось чинити. Але! Це був типовий win-win: адміни зазвичай набирали декілька таких клієнтів, отримували надприбутки якщо нічого не ламалося, а також мали сильну мотивацію тримати серверні справи в такому стані щоб інцидентів було як можна менше.

Учасник 2: Клієнтський сервіс
«Живий» сервер — це важлива складова кастомерского щастя, але не достатня. Тому важливо мати передовий спеціальний загін для швидкого реагування на проблеми кастомерів. Це спеціальна команда (може бути розподілена), робота якої обробляти вхідні запити від кастомірів: допомагати, категоризувати та приймати відповідні рішення. Важлива деталь: команда підтримки має мати чітки інструкціі на ВСЕ: що робити, що коли відповідати, які кнопки тиснути, кого будити далі якщо не спрацювало.

Учасник 3: Техлід (може бути також CTO, або топ-сіньйор)
Якщо адміни і Customer Support не можуть вирішити проблему, тут, звичайно, все прилітало саме мені як ліду, і це нормально. По-перше, мені за це платили *N грошей. По-друге, якщо вже така жесть прилітає, то потрібно максимально широко знати систему, потрібно знати, де що подивитись і як швидко локалізувати. У великому проєкті не кожен девелопер навіть має доступ до всіх компонентів. А якщо і має, не факт що мав з ним справу до цього. По-третє, у ліда є широкі повноваження (плюс особистий інтерес не допускати повторення інцидента в майбутньому), і я завжди цим користувався. Т/т може і повинен покращувати процеси, тиснути на процеси QA або Customer Support Team, доносити стейкхолдерам, корегувати девелопмент плани за результатами інциденту. Тому, кількість таких інцидентів падала до 1-2 на рік, а то й менше.

А просто так постійно напрягати всю девелопмент тіму роками, чергуваннями (!!!), для мене виглядає термінально тупо.

P.S А про інші топові ініциативи сучасної індустріі типу «no QA movement» я взагалі мовчу, в мене є 5-7 прекрасних історій про результати такого мувменента, але не можу видати бо NDA. Я звик це сприймати як спорт: ну хтось придумав бити м’ячем ногами по воротах, хтось придумав кодити без QA; ну хоче замовник, чому б ні.

А просто так постійно напрягати всю девелопмент тіму роками, чергуваннями (!!!), для мене виглядає термінально тупо.

Для мене тупо виглядає постійно самому бути на чергуванні)
Чим нижчий рівень людини, тим більше її можна експлуатувати.
Хотів б я побачити як CTO великої компанії в логах копається

CTO великої компаніі ніяк не може колупатись, це вірно, то буде сіньйор або теклід, а CTO стартапа на 5-6 людей я бачив регулярно за такою активністю, у різних проєктах, нічого тут сакрального немає. В стартапи за тим і ходять щоб потім був C-level в резюме.

Але якщо ми про великі проєкти, то там від рандомного девелопера користі взагалі нуль, що він з тими логами робитиме в три години ночі, навіть якщо отримає до них доступ? (А також якимось дивом отримає вночі доступ до сорців саме того компонента) Потім що, фіксить буде? Так він його не збере сам, а якщо і збере то не зможе потестувати навіть. А пушать в великих проектах часто взагалі окреми тіми (не обов’язково, но так теж буває). Тобто кодіть вночі він явно не буде. А якщо це не девелопмент, то навіщо там саме девелопер? В тих великих проєктах де я був це в 99.(9)% кейсів це хендлилось спеціальним суппортом, див вище.

А якщо вже трапилося щось екстраординарне прям, то най там краще буду я (як теклід) а не рандомний девелопер, бо я маю доступ до бази інцидентів, можу підняти коммунікацію з замовниками, знаю (або можу підняти всі прийняті ключові рішення) по технологіях і інших змінах. Можу написати sorry letter ключовому клієнту з планом дій, прогнозами та таке інше (якщо в нас b2c), в мене більше шансів придумати work around, і вже точно більше шансів залучити правильного експерта, якщо в нас реально фокс-мажор. І цей форс мажор буде мене ще більше мотивувати імпрувити процесс, ось що важливо, я про це вже писав.

P.S Little update

постійно самому бути на чергуванні

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

В стартапі з 5-6 людей СТО це часто єдиний розробник. СFO, CMO, CIO, COO, CEO в код не полізуть)

Вам вже написали, мабуть: oncall суттєво знижує якість життя.
Із особистого досвіду:
— один тиждень на місяць ще можна терпіти, частіше — важко, ви ніби живете на роботі, постійно в напруженні.
— 13″ макбук про + телефон з гарною батарейкою і передоплаченим інтернетом. Якщо компанія не надає телефони, підніміть це питання, це важливо. Номер, на який вам будуть дзвонити, то також повинен бути телефон компанії. Взагалі намагайтесь уникати будь якої взаємодії за допомогою особистих девайсів.
— мене був навіть якийсь фітнес браслет, щоб можна було плавати в басейні, коли телефон замкнений у шафці.
— не можна бухати. Хоча це мабуть скоріше плюс...

Щодо оплати, як правило є фіксована плата за «зміну» + погодинна плата за кожен інцидент (поза робочим часом). Чи варте воно того? Я думаю, ні, але це дійсно стає нормою.

Я просто залишу це тут: https://sre.google/sre-book/being-on-call/

коли є продукт як сервіс, і коли шось лежить всираються гроші і репутація там завжди є онколи. Для українського аутсорсу і аутстафу то може дико, але то я є стандарт у ельфії.

Є сервсі для онколів, де є час реагування, ретраї, дзвінки, переадресація на інших участників. Зазвичай перша дія то acknowledge, шо б більше система не пінгувала, а далі дивитись шо за проблема.То все налаштовується на конкретний кейс.

Великий антипатерн онколів вішати все на одну людину, на онколі сидять всі. Бо якшо людина звалює то стрес для всіх. У вашому випадку це вже було не правильно.

Так 3 людини мало, але тут треба гратись з пріорітетами на шо йдуть альорти.

В різних компаніях онколи зміни можуть уйти по різному, 4/3(пт+вихідні), потижнево, по 12/12(годин у кейсі півкоманди сидить в америці наприклад), у деяких тільки buisness hours, знову ж таки пер кейс

В нормальних компаніях за тиждень онкола дають або вихідний або платять. Зазвичай якшо проблема зявляється в нерабочий час, людина трекає і потім бере цей час як time-off.

так он-кол це напряжно, але в нас не рабство, не подобається шукай нову роботу.

п.с. деякі чувак раді взяти онколи інших людей бо їм бабло потрібніше

Прочитавши коментарі зрозумів: Онколи є там, де економлять час і гроші на тестуванні.

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

Тестування і навіть запропонована тут автоматизація куброклаудами тут ні до чого. Он кол є там, де всю ніч лежачий сервіс навіть декілька разів на рік приносить збитків набагато більше ніж вартує забезпечення онкола. Може бути недоотримане ревенью, може бути падіння вартості акцій на фоні таких новин (згадай падіння фейбука після зміни BGP таблиць), можуть бути штрафні санкції за незабезпечення SLA.

Чому сервіс стає лежачим в певний момент?

Заекспайрился один з сертифікатів чи ключів, десь переповнився диск, десь щось змінилося в залежностях на екстернал сервісах, переповнилася памʼять, стався лок в базі ну і ще може бути мільйон причин. В серед них так, звичайні баги, які в якийсь час вилазять і на продакшн і треба відкотитися на попередню версію.

Тобто сталася неочікувана ситуація яку не змогла захендлити наша система.
Майже на кожен із описаних кейсів є свій юніт-тест, інтегрейшн тест, тестування інфри, різні типи тестування продуктивності(load, stress, volume, etc.) і багато чого іншого. Окрім того є ще така цікава практика як хаос-інжинірінг, але це вже дещо екзотика.

Команда на чолі із замовником або приймає рішення робити продукт по бест-практикам і з якістю або тестувати на юзерах і з онкол-командою.

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

онколл — це процесс. Тобто наявність онколла як процеса нічого не каже про якість. Так само як наявність супорта не каже нічого про якість. Ось як часто стаються ці інціденти які вимагають реакції спеціаліста на онколі — о це вже може шось сказати про якість і практики.

Я поки що не бачив сервісів, які покриті на 100% юніт чи інтегрейшн тестами. Може якісь ядерні реактори таке і мають, але зазвичай вони не працюють всякими спрінтами і пошвидше в продакшн і на маркет.

Ок, питань більше не маю.

Мені просто не хочеться приймати той факт, що велика частина продуктів свідомо визнають, що вони будуть падать в продакшені з певною регулярністю і це для них нормально.
Особливо враховуючи те, що частину з цих падінь можна було б попередити просто додавши 1-2 тижня більш глибокого тестування і ще 1-2 тижня на багфікс результатів цього тестування.

Навіть корпорації періодично переносять релізи своїх продуктів, релізи айфонів неодноразово здвигалися, що тоді казати, що відтермінування релізу якогось локального інтернет-магазину для підвищення його якості точно не має стати проблемою.

Фізичний продукт аля айфон звичайно повинен бути більш ретельно протестований, бо на нього не завжди можна патч викатити, як це було наприклад з проблемою антени в 4 здається версії.
Зараз часи контініус делівері, транк-бейзд девелопмент, інфрастрракче ез е код і все таке інше, дешевше швидко виявити і вшидко зафіксити, додавши тестів на майбутьне, ніж наймати додатково персонал все це ретельно тестити і повертатися до релізів раз на півроку як це було, коли софт на сд-дисках релізився.

Мені просто не хочеться приймати той факт, що велика частина продуктів свідомо визнають, що вони будуть падать в продакшені з певною регулярністю і це для них нормально.

Вочевидь не ламається тільки те що не працює. Це обʼєктивна реальність яку треба усвідомлювати.
Усвідомлення того що факту що продукт буде падати в продакшені допомагає прийняти рішення і вибудувати процеси що допоможуть мінімізувати втрати від таких падінь.

Боже та звичайний хелс чек на єкстернал потім вже показ юзеру що сорян поки що на паузі, ти хоч би почитав як перестали писати сервіси 10 років тому.

Бо мати купу залежностей а потім дозволяти усим сервісам що залежать срати єксепшени ну це майже перше зо питають на співбесіді для розподілених систем

Ну і архітектор як раз для цього щоб думати про авілабіліти та резистентність системи, це перші кейси що обдумують коли додають сторонні сервіси, а не малювати графіки для прісейлу.

Да уж, крім тебе ці 10 років ніхто більше сервісів не писав, і просто не знали пацани що можна хелс чек повісити і готово. Ну все, відміняємо онколл, тепер заживемо з хелс чекамі.

А шо пацани в три ночі пишуть заміну серд паті сервісу? Ну блін Серьога хоч почитай як пишуться розподілені системи а не цю маячню нести, що у вас падають в ночі сервіси і ви їх фіксите, бо це дурка повна.

А головне що авілабіліті, фолт толеранс, дізастер рекавері та інші практики вивели ще давно, коли великі компанії робили всю цю автоматизацію самі, а не зараз з клаудами, кубером та клаудфлером та іншим коли в інеті повно книжок та сервісів напів готових.

Ну так якщо ти про все це читав почитай ще про те навіщо потрібна окрема роль SRE і чому у всіх великих компаніях, які на цих розподілених сервісах собаку з’їли досі існує онкол ;-)

Про сре написав тобі ще раніше, це зовсім інше і це не робота програміста, вообще не його.

В догонку, ці компанії мають он кол, не тому що в них падає серд парту сервіс чи лок на базі, я тут писали, а чере те що вони віпідорашують авілабіліті на гіперскладній системі з охрінівшим навантаженням 24 на 7 та часто по всій земній кулі, і там він ну зовсім для внешатаної ситуації, коли атоматизація та купа практик вже не впоралась.
І ще, випідорошувати оці долі відсотків для них є профітабл та перекриває цей супорт.

Он кол є там, де всю ніч лежачий сервіс навіть декілька разів на рік приносить збитків набагато більше ніж вартує забезпечення онкола
А шо пацани в три ночі пишуть заміну серд паті сервісу?

На питання відповідає чатжпт, бо мені ліньки:

When a third-party service dependency fails, the on-call team’s primary goal is to mitigate the impact on your own service and its users. Here’s a step-by-step guide on what the on-call team can do in such a scenario:

Alert and Detection: Monitoring systems should promptly detect the failure of the third-party service. These systems should trigger alerts to notify the on-call team of the issue.

Assessment: The on-call team should quickly assess the nature and scope of the third-party service failure. Determine which aspects of your service are affected and to what extent.

Communication: Inform relevant stakeholders, including internal teams, leadership, and potentially users (if appropriate), about the issue and its impact. Transparency in communication is crucial to managing user expectations.

Workaround or Failover: If possible, implement a temporary workaround or failover mechanism that allows your service to continue functioning with reduced functionality or an alternative approach. This could involve rerouting traffic, utilizing cached data, or utilizing other services.

Engage Third Party: Contact the third-party service provider’s support team to report the issue and request assistance. Provide them with relevant information about the impact on your service and any troubleshooting steps you’ve taken.

Monitor and Escalate: Continuously monitor the situation to track any changes or updates from the third-party service provider. If the situation worsens or the third-party service provider fails to provide timely assistance, escalate the issue within your own organization and with the provider.

Update Users: Keep users informed about the progress of the issue and any steps being taken to address it. Provide estimated timelines for resolution and updates as you receive them.

Analyze Impact: Assess the impact of the third-party service failure on your service’s performance, availability, and user experience. This analysis will be valuable for post-incident reviews and future contingency planning.

Resolution and Recovery: Once the third-party service is restored, verify its functionality and ensure that your service can safely transition back to normal operation. Communicate the resolution to users and stakeholders.

Post-Incident Review: After the incident is resolved, conduct a post-incident review to analyze the root cause of the third-party service failure and evaluate your team’s response. Identify lessons learned and areas for improvement in your incident response process.

Documentation: Document the incident, including the timeline of events, actions taken, communication details, and outcomes. This documentation will be valuable for future reference and for training new team members.

Prevention and Mitigation: Consider implementing strategies to reduce the impact of future third-party service failures, such as using alternative providers, implementing redundancy, or creating contingency plans for similar incidents.

In summary, the on-call team’s role in the event of a third-party service failure involves timely detection, communication, mitigation, and resolution to minimize the impact on your own service and its users. Effective incident response practices are essential to ensure a swift and well-coordinated response to such situations.

Communication: Inform relevant stakeholders

от після цього навіть не читав :-)

Тобто твій солюшен — залити код на прод що критично залежить від серд парті сервісу, без ніякого плану на випадок що воно впаде, а потім питати у чат жпт в три ночі що робити і будити стейкхолдерів? ти наркоман? :-)

Наркоманія — це сперечатися з чатом жпт :)

ну і он кол супорт є різний, є для інфоаструктури, це коли діди написали на зрестах і ніхто не хоче міняти нічого а клауди то зло.

для коду, це коли лайнокод у прод бо тестувальнів не треба, юніт тестів не треба, тех лідів також, ми продукт і все на колінцях робимо.

онкол супорт бо така бізнес модель типа кліентам відповідати то вже зовсім інше.

он кол це ред маркер гівнокоду та всратиз процесів, хіба що там пишуть онлайн банкінг коли кліенти в усих часових поясах, або постійне високе навантаження 24 на 7, і то далеко не завжди.

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

Так прикинь, є вся автоматизація, кубер в клауді і всі те про що ти як так розумію тільки в книжках читав. Тому що і онкол при цьому є.
Твій кубер в клауд точно так же буде тобі слати алерти, на які хтось повинен реагувати, тому що він поки що не вміє фіксіти всі можливі варіанти крім банального рестарта сервіса чи авто скейлінга.
Чомусь в Гуглі, який цей твій улюблений кубер і розробив і свій клауд теж має при цьому має і онколи. І тільки продвинутий автоматізатор на доу знає як правильно процеси налогодити щоб нічого ніколи не падало :)

І що робить он кол в таких випадках? Ну от правда, фіксить баг і заливає на прод? Ну блін та навіть далеко не в усих є пермішені в дев мержити не то що на прод лізти.

Якщо ти звик ліпити костилі на прод, без тестування то так і скажи.

Взагалі програміст не є сайт релайабіліы інженер, ві може взагалі жупля не відстрелювати як працювати з тулами для цього. Ну і секьюріті як тоді? Креди на прод у чатіку для онколу? :-)))

Онкол для продукту як частина сервісу так, норма, але програмісти на онколі це редмаркер гівнокоду в продакшені як частина процесів, можеш виправдовувати онколом гугла сікільки завгодно.

У тих самих фангів є SRE чи щось подібне, типу девопс що займається таким і це частина роботи, прописана в контракті та обговорюється ще на перших єтапах.

Програмістам там робити нефіг, бо не секьюрно та не його профіль.

Програміст на онколі то гівнокод та жлоб менджмент у 90% випадків.

Так, программіст умовного сервісу як частини продукту останній в цьому ланцюжку онкола, в більшості випадків якихось збоїв до нього черга не доходить. До цього є інцідент менеджери і нетворкінг інженери.

В Амазоні і Гуглі деви онколл на додачу до SRE (хоча в Амазоні їх нема, тому там тільки деви). Можеш на блайнді почитати, наприклад

It’s pretty bad I would say. Others have touched on it but if your team gets paged often (might be fairly likely) you have to block out your time for the whole week.
I got paged many times in middle of night and have had straight panic attacks from the stress. It’s the only thing that’s done this to me in years. It’s literally stressful just going to bed knowing your pager might go off in a few hours.

Of course you won’t get paid extra In my experience, on a team like yours, the load will increase as soon as you gain more customers / move out of beta and your life every X weeks might be hellish. It’s a big risk. I would urge you to not join Amazon.

От лошари, не могли EKS заюзати )

Я вже заїбався писати очевидне, можете висіти на онколах та доводити що ви як у гуглі.
Програміст на он колі це костиль та гівномеджмент, те що воно є в гуглі та амазоні, підтверджує що і там є гівнопроекти.

З безлічі причин, які не можливо передбачити.

В такий організації тебе негайно замінять, як того техліда. Коли воно так організовано, то власник з гарантією має авторитарну систему управління. Ти йому надаш пропозицію — він тебе вижене. Зазвичай такі чергування це коли з грошима усе погано, софт гімно написаний мало не на дурняк в Індії в тричі коротше ніж треба тощо. Як не крути доведеться йти або різко, або по трохи насправді різниця не велика. Краще проаналізувати чому потрапляєш в таку ситуацію. Я коли аналізував прийшов до чіткого висновку, що займався легасі тобто саме там де процвітає такий тип управління. Більше нізащо не погоджуюсь на легасі і нікому не раджу їм взагалі займатись. Якщо той Тітанік тоне в морі лайна — нехай тоне зі своїм капітаном разом, а не вам дадуть надувний круг і дуй туди во всю дурь щоб воно не тонуло, допоки лайно прибуває в пробоїни. Коли скажеш досить з мене, давайте хтось компресор приладимо — викинуть за борт на мороз, на прощання скажуть що ти дурень і є компресор тільки дешевше . Були би гроші на компресор — ти взагалі був би не треба, його би обслуговував сертифікований білий від компанії виробника.

Тут залежить від ситуації.

Якщо видати в лоба «Твій софт гавно» youtu.be/oeJ7_tVJWOI
То результат буде очікувано негативним.
А якщо спробувати продати своє рішення більш адекватно — може й погодяться.

Там наївних нема, зазвичай вони чудово знають що в них за софт. Були би гроші — робили би новий. Не цифрових бізнесів по закордонах майже не лишилось років так з 15 тому, вони усі по вимирали як ті динозаври. Ті хто вижив та залишився на плаву, при наявній конкуренції, чудово розуміють що до чого. Коли вони сапортять легасі, роблять ті самі чергування, то чудово розуміють — що там баг на базі, чи взагалі один суцільний баг. Просто треба лохи за дешево на сапорт. Ще є дурні які думають, що от зараз вони візьмуть висококваліфіковану людину яка зможе компенсувати це гімно та оперативно підфікшувати. Насправді ні — бо треба дуже добре знати той проект, а його не знають навіть ті індуси які його писали. Та і це просто може бути не по силам одній людині. Коротше легасі дорівнює реплатформінгу, або банкрутству. Добре написаний продукт постійно розвивається, та взагалі не стає в стан легасі.

Онколи є там де це доцільно з економічної точки зору.

Особливо мені подобався аргумент замовника «В Сіліконовій долині всі так працююють, чого ви не хочете онколл?» Я кажу «А можна мені зарплату як в Силиконовій долині? І стоки!»

P.S. Я можу в позаробочий час щось починити якщо бачу що прод падає, але прям підписатися на сапорт і ходити навіть в кіно з ноутбуком це було б too much

В данному випадку, коли це економічна діяльність не існує ніяких: «А можна?». Це коштує стільки і усе, не подобається — шукайте тих кому подобається. І насправді знайти буде не так вже і просто, на дурняк принаймні.

це не так страшно, як здається
основний лайвхак не обирати user faced проєкти з високими рівнями SLA

Я би потрійну і то не факт, що є сенс підписуватись. Є речі які не під силу одній людині. При усьому бажанні навіть самий крутий штангіст не підніме штангу вагою в тонну. Але зробивши спробу легко можна надірвати пупа, та наробити іншої шкоди здоров’ю.

Тут багато хороших коментів по ділу. Звичайно у вас має бути хороший ноутбук, бо ж їхати в офіс посеред ночі — це дикість. Та і поки доїдете, уже багато проблем може набратися(:.
А так головне зрозуміти які саме очікування (SLA, SLO) від вас будуть, як часто будете змінюватися (це обов’язково, в ідеалі 4+ людини мають брати участь в ротейшені).
Маючи цю інформацію, розумітимете об’єм додаткового навантаження, і що справедливо очікувати у якості компенсації за нього.
Тих хто пише що онколів ніде нема не слухайте, в успішних продуктових компаніях, особливо топових — онкол це скоріше норма. Ідея в тому, що програмісти несуть відповідальність за свій код у тому числі в продакшені. При цьому також чесно, якщо роботодавець дає час на покращення надійності сервісів, а не тільки жене нові фічи релізити. Якщо все добре, то компанія в результаті онколів має більш надійні і стабільні сервіси (програмісти вставати вночі не хочуть фіксити щось). А розробники просинаються дуже рідко, знову ж таки, завдяки стабільному продукту. Він-він.

Ідея в тому, що програмісти несуть відповідальність за свій код у тому числі в продакшені.

Якщо відвалилась 3rd party якась то теж програміст відповідальний? Бо ті що на L0 не сильно розбираються у чому проблема і напрягають програміста

Не особисто програміст, але команда-оунер залежного сервісу так, звичайно. В їх силах підключити кілька 3rd-party аналогів, і переключатися між ними у випадку фейла непомітно для користувачів. Або ж, якщо з точки зору продукта це прийнятно, показувати користувачам адекватне повідомлення про тимчасову недоступність і рекомендацію спробувати ще. Або ж це саме плюс плейбук для L0 саппорта, як перевірити доступність 3rd-party.
В цьому і суть правильного онкола, що у всіх є мотивація робити продукт кращим.

Не особисто програміст, але команда-оунер залежного сервісу так, звичайно.

В них два джуно-міда дева і звільнений лід.

Прикольно ви нас з колегою опустили, дякую))

Перепрошую якщо вас образив, але з ваших запитань і топіка очевидно що досвіду роботи сіньором у вас немає)

Без образ, просто цікаво, а з чого конкретно видно — з того, що ніколи не стикалась з онколами і цікавлюсь організаційними моментами?

З ваших питань і відповідей)
Наприклад

звільнили техліда, який був відповідальний за проблеми на проекті в будь-який час доби. Тепер on-call зміни хочуть поставити нам, звичайним девелоперам.

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

Зрозуміла :)
Я тепер на будь-якій співбесіді буду сама про ці онколи запитувати, щоб не влипнути ненароком))

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

Було, подвійна доплата за відпрацьовані години, вигорів як чорт, на таких умовах newer again.
До речі, тімлід можливо також вигорів і його звільнили. Непоганий спосіб дропнути команду, як на мене, якщо це вводиться директивно без попередження.

Вас не насторожує — що тех ліда вже звільнили ?

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

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

Я б радив сказати що ви контрактор і онколить не будете. Бо онкол то скоріше стрес ніж робота

Це називається «На зло мамі відморожу вуха»

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

Мені здалося що шукають особисту пораду, але очевидно що то менеджеру на галєрі розбиратись в таких речах.

Стосовно конфлікту і коетракторства — на заході відношення до контракторів сильно інше ніж в Україні. І якщо контрактор отримує гроші не по годинам а за дні, то цілком логічно не працювати більше 8 годин. Емплої отримують значно більше бонусів і можливостей від компанії, тому і очікування від них інші

Там куди гірші наслідки для здоров’я можуть бути ніж просто психологічні проблеми чи втомленість, вона запросто може стати хронічною. Це важка робота тому 5% це звісно просто обман замовником, коштує це набагато дорожче ніж 5%. Та і взагалі основну роботу ніхто не знімає з вам, а ще додаткову з гори вішають.

Це важка робота тому 5% це звісно просто обман замовником, коштує це набагато дорожче ніж 5%

КоштуваЛО, коли в Україні не було війни. Зараз і така робота для багатьох за щастя.

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

У вас немає сім’ї та дітей верогідно. А в багатьох є. І їм треба щось їсти. Роботи в Україні дедалі менше. І багато хто з радістю погодиться працювати замість вас на он-колах, якщо з якихось причин ви брикнете і відмовитеся.

Є і сімʼя, і син. І чоловік поки що з роботою, на щастя.
Щодо «багато хто» маю сумніви, бо чомусь на проекти замовника дуже довго шукають людей, незважаючи на загальну ситуацію на ринку. Можливо, українців замовник зараз і не розглядає, а от в тій же Румунії до них черга бажаючих не стоїть, навпаки — незадоволені люди регулярно звільняються (наприклад, у лютому купа людей звільнилась, бо були незадоволені, навіть ображені річним salary review).

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

P.S. Така ідеологія нажаль призводе до вкарай поганих наслідків по результатам усіх попередніх криз. Якщо не подобається треба брати ноги в руки, та шукати де краще, підвищувати кваліфікацію, шукати нових клієнтів постійно. Триматись за соломинку верхи на здохлій кобилі, це стратегія часу в нікуди, стратегія оберігання власної зони комфорту, яка перетворює життя на суцільний дискомфорт.

1) Було, ротейшн по тижню (тобто цілий тиждень на онколі, потім зміна). Людей було на 1 проєкті десь 4, на другом 3
2) Особливо notice періода не було, також була secondary людина (якщо проспав і не заакав, алерт йшов на неї). Ми юзали PagerDuty
3) Доплати були: на одному з проєктів per fixed alert, на іншому просто фіксована доплата
4) Активності: тут так, трохи незручно. Треба було носити ноут з собою, якщо наприклад десь в неділю вийшов в центр погуляти. В зал не носив ноут, фартило що алерти не приходили (але це ризик :) ). Але загалом онкол трохи геморна справа — деколи наприклад серед ночі могла прийти якась херня в 3 ночі і тобі фіксати або ескалейтати і когось будити. Або коли ти за кермом додому їдеш і приходить якась крітікал штука. Стараюсь проєкти з онколами обходити трохи

Головне у всьому цьому правильно налаштувати алертінг і не відкладати на потім наприклад алерти аля «а, це херня, через 5 хв алерт сам закриється», краще залізти на другий день в моніторинг систему і підкрутити якісь трешхолди, таймаути і тд

Ну і ще якщо маєш якісь активності на вихідні або будній день або ще щось, то ми просто домовлялись між собою і ротейтились там навіть на годину якусь в PD або на цілий вихідний день (якщо людина не збиралась наприклад нікуди на вихідні). Тому викрутитись можна. Але все рівно, лишній гемор. Краще найти вакансію без онколів і з більшою зп і не паритись (зараз звичайно це трохи важче)

вакансію без онколів і з більшою зп

Самому не смішно від такого? :)

Якщо нормально не прописано що вважається крітікал інцидентом, то вас будуть штурхати майже кожного дня. Щось типу з серії подивись чого у нас прибуток впав на 0.5 %, замовник скаже ну це бага мабуть шукайте, потім через годину пошуків ви найдете що хтось з маретологів забув додати якусь групу юзерів. І таке буде майже щодня, подумайте чи воно вам треба.

Для початку треба зрозуміти скільки таких випадків в середньому за місяць. На який рівень доступності розраховує клієнт і для чого воно йому потрібно. Далі можна зробити брейншторм мітинг з командою і вирішити як найкраще виконати такі забаганки. Є багато ситуацій коли навіть якщо у вас зміни будуть перекривати 24 на 7 це все одно не дозволить підтримувати потрібний рівень сервісу.
Ось наприклад для чого іноді просять щоб людина «посиділа» в неробочий час
1) Важливий деплой
2) Моніторінг системи поки є підозри що вона може бути нестабільною
3) Система може будит сконфігурована тільки технічним спеціалістом і час від часу така потреба виникає
4) В них є система моніторингу відгуків користувачів і жорсткий таймінг по реагуванню на скарги
5) Система це нестабільний шмат чогось неприємного і якщо не тримати руку на пульсі все може розвалитися.

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

Для початку треба зрозуміти скільки таких випадків в середньому за місяць.

Яка різниця, коли навіть усамітнитись з дівчиною (хлопцем) не можна без постійної готовности зупинитись і переключитись на роботу?

Ні, хтось в онколлі — він на роботі. Все. ;(

Тут можно только посоветовать поставить профиль на Джине в активный статус. И через неделю, от того, что там видно по активности уже принимать какие-то решения.

Був досвід коли раз на тиждень робочий день зміщувався на 8 годин, і закінчувався, таким чином, в 3 ночі. Виходила підтримка 16 годин на день. А щоб 24 — ну, це жорстко..

На заводах/фабриках зазвичай технічні служби працюють так: денна зміна (8-20) — на наступний день нічна зміна (20-8) — день відсипний — день вихідний — потім все спочатку. + робота у ненормовані (нічні) години мусить оплачуватись по подвійному тарифу. У вас (якщо я правильно зрозумів) ситуація дещо інша — ви працюєте за звичайним графіком + вас змушують працювати додатково (так звані on-call зміни). В такому разі ви маєте право відмовити або диктувати роботодавцю свої умови (наприклад оплата x2..x3). Керівництво звільнило працівника який займається on-call змінами? — це не ваші проблеми, воно мусить усвідомлювати наслідки своїх дій.

Актуальна стаття:
minjust.gov.ua/m/str_8396

Причем тут Минюст, с 99% вероятностью там оформление через ФОП, уволить могут за 2 часа без любых последствий.

Нет не подходит, так как весь ИТ оформлен через ФОП, у нас все независимые консультанты на сдельной работе, а не наемные рабочие для которых все эти нормы. Вот сказал заказчик, что нужен Онкол 24 часа 7 дней в неделю иначе платить не будет, и все, не нравится — гуляй.

В такому разі немає сенсу створювати даний топік, оскільки

Вот сказал заказчик, что нужен Онкол 24 часа 7 дней в неделю иначе платить не будет, и все, не нравится — гуляй.

Ну, один человек в любом случае 24/7 не потянет. Если хотя бы двое, то могут по очереди вытягивать требования заказчика.

ФОП, уволить могут за 2 часа без любых последствий.

Ага, ага, техліда вже, здається, звільнили без жодних наслідків.

Він, до речі, був не ФОП, а звичайний собі найманий працівник в своїй румунській компанії)) Просто йому поставили ультиматум: або підписує заяву на звільнення, або починає ходити в офіс замість ремоуту (знали, що він не погодиться)

Він, до речі, був не ФОП, а звичайний собі найманий працівник в своїй румунській компанії)) Просто йому поставили ультиматум: або підписує заяву на звільнення, або починає ходити в офіс замість ремоуту (знали, що він не погодиться)

Яка в вас дружня компанія. Техліда зажали та звільнили, а ви розповідаєте про це зі смайликами.
Впевнений, що ніхто з команди навіть не вписався за тімліда.

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

Смайлики були стосовно порівняння ФОП і найманих працівників — іронічно, але позиція найманого працівника не рятує від легкого звільнення, на жаль.
Що стосується «вписався», так ми взагалі з різних аутстаф-компаній, і особисто я не знайома з його менеджментом. Як ви собі уявляєте процес «вписування» в даному випадку? Це внутрішня справа його компанії, його менеджмент не слухає навіть наших PM зі сторони британського замовника (які вже пробували вписатись за попереднього куа, але були проігноровані)

або починає ходити в офіс замість ремоуту

on-call’ить их чем-то не устраивает на удалёнке?

Вони просто запропонували перевести його з ремоуту в офіс, назавжди, не тільки на онколи. Ясно, що це був просто привід змусити людину звільнитись. Він дуже любив проект, але хотів (цілком справедливо) більшу зарплату. А компанія не захотіла платити.

так бы и сказали прямо, что не будем платить. Бесит когда начинают выдумывать схемы дурацкие. Ну ок, спс за уточнение

Ну тут таке. У офісі як засидишся, приходе охорона — та дасть копняка під зад додому. І через різницю в часі, нажаль завжди засиджуєшся. Так воно працює. При чому коли різниця в 7 годин із США та Канадою, воно працює краще за різницю в 2 години з Англією. Ну і банально більш нормальний ритм життя. Прикольно мати можливість пару днів на тиждень з дому, 100% видаленка таке собі. З таких проектів йдуть якраз через те що ми обговорюємо, нереальні очікування від безпосереднього керівництва проекту, нестача строків та бюджету, занадто амбіційні плани, виручка меньша за заплановану тощо.

Або для цього є відповідні люди на відповідній зарплатні.

Тобто Гугл, Амазон чи Мета — не нормальні місця?(:

ну є сервіси які дійсно мають працювати 24-7 і в випадку проблеми — фіксити її максимально швидко. І це здається нормально і очікуване, ні?
Якщо це всіх влаштовує на проекті, добре оплачується і нормально побудован процес — не бачу проблеми взагалі.

Ну це сильно залежить від проекту, один раз я погодився, за +10% до зп. Але там проект був з невеликою кількістю користувачів з піками в певні періоди року. За кілька місяців у мене було аж 3 інциденти (і це притому що на онколах нас було двоє). Якщо є побоювання що інциденти будуть кілька разів на тиждень а не раз на місяць то краще взагалі не погоджуватись.

Ви вважаєте що онкол це в принципі ненормально? Це скоріш говорить про те що ви не розробляли нічого серйозніше за інтернет-магазин

Я просто хочу запитати, чи був у когось подібний досвід.

В минулій компанії (в Україні, аутсорс) кожному діставався тиждень онкола раз на ~місяць. Компенсувався додатковою відпусткою, але багатьох це не влаштовувало, і коли ввели on-call, це було постійним джерелом скарг та напруги.

В Європі би ніхто на таке не погодився.

В Європі би ніхто на таке не погодився.

І як же працюють Гугли і Убери всякі в Європі, якщо ніхто не погодився б?(:

я так розумію автор мав на увазі онколить без фінансової компенсації за онкол.

Може, добові чергування через три. Може, тиждень по 8-12 годин, але не повна доба, решту доби забезпечують інші люди. Є різні варіанти...

чи був у когось подібний досвід.

Був, тому в профілі в джині написав що розглядаю тільки вакансії без онколлу.

Який був графік змін (і скільки при цьому людей в команді)?

2 тижні чергування, 4 тижні ні.

Чи був якийсь notice period дістатись до робочого місця?

Ні, в офіс не треба було їздити. передбачається що ти віддалено вирішиш всі проблеми (тому має бути ноут, норм навушники, інтернет).
Це називається SLA (service level agreement). Все залежить від проекту, в мене було 15 хв реакція на критичну проблему. Тобто можна і з телефону написати «дивлюсь до цього». Часто дзвонить супорт і просить заджойнитись на колл допомогти подитись логи, розібратись в проблемі.

І як виходило суміщати це «щастя» з нормальним життям

З нормальним ніяк. Треба постійно таскати з собою ноут.

Доплати, компенсації?

Залежить від проекту, в мене було фіксована доплата за доступність (150$ в тиждень) і Х2 рейт за потрачений час.

Підсумовуючи, я так працював рік, будучи техлідом. Досвід дуже негативний, от колишеш дитину а тобі дзвонять.
Пізніше найняли ще одну людину і я перевів всі онколи на девів, сам хіба в слаку міг щось відписати/підказати.

Насправді до таких штук команда розробки має бути готова перед тим як це імплементувати — правильно прописані SLO на кожен сервіс, налаштовані алерти, трекінг інцидентів, враховувати час того хто на on-call при плануванні задач і т.д.

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

Виходячи з вашого тексту — ви займаєтесь розробкою/суппортом якогось невеликого апплікейшина, де все тупо трималось на одній людині яка була пожежником у випадку коли шось траплялось. Зараз просто треба інший пожежник, якого менеджмент буде кошмарить коли буде треба.

Навіть якщо вам будуть доплачувать x2-x3 (чого скоріш за все не буде) головняка у вас буде дуже багато. А якщо інцидентів у вас до цього було немало, то потенційно це пряма дорога до тривожності стресу.

Ще раз повторюсь, до цього команда розробки/продукт має бути готовим.

Дякую за вашу думку, згодна на 100%.

Ще раз повторюсь, до цього команда розробки/продукт має бути готовим

Тільки в нас ти вночі онколл, а зранку на роботу треба йти закривати сторі пойнти.
В Німеччині за таке вже б засудили.
Є робочий день з робочими годинами. Хочеш щоб була технічна підтримка 24/7 — створюй технічну супорт команду, вводь позмінну роботу, плати відповідно до закону.
Ось так воно і працює в нормальних країнах.
А в нас, «та шо там того онколлу, то ж не кожну ніч дзвонять». Та й взагалі, ти ж це девелопив, а зараз там проблеми, фіксай.

в Німеччині воно працює так само як і в інших крїнах

Не сравнивай рабочий контракт и ФОП.

Так звичайно
Зазвичай зміна на тиждень, час на реакцію до 1 години
Основна задача — підняти впавший сервіс, а не робити якісь фікси. Тому з часом пишуться сценарії на всі випадки падіння і в онколі можуть брати участь люди навіть якщо не знають повністю систему
В FAANG онколи як провило є скрізь і вони не оплачуються окремо. Якщо це український аутсорс, то без доп оплати я би в це не ліз

В FAANG онколи як провило є скрізь і вони не оплачуються окремо.

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

просто цікаво — в яких країнах і яких фангах окремо доплачують за онколи?

It Craft (контора топікстартера) !=FAANG. Середня галера то також не фаанг. Тиждень в місяць не жити за 200к/у я згоден, а за 3-6к/mo — ні.

Просто клінічні довб***би. Тобто був терпіла, який готовий був підставлятись 24/7 і вони його звільнили, лол.

Доплати, компенсації?

Не було. Але оскільки я працюю зазвичай до 40 годин в тиждень, а вони хочуть доступність 168 годин в тиждень — я би просто ЗП х4 виставив і хай платять. За такі гроші готовий би ходити в туалет з ноутом в руках.

ЗП х4 виставив і хай платять. За такі гроші готовий би ходити в туалет з ноутом в руках.

Короткочасно — так. На довгій дистанції поїде кукуха. Грубо кажучи, толку від тієї зарплатні, якщо від ноута та телефона навіть уві сні відійти не можеш)

Пів-року накосити баблішка і можна взагалі зі спокійною душею відпочивати місяць.

В сраку таку роботу. Для цього існує техпідтримка 24/7.

У мене тім 6 девопсів + техлід. Он-кол по 2е, один праймарі, на нього йдуть повідомлення одразу, якщо протягом 5 хв не підтверджує (ACK) через аплікуху, йде алерт на секондарі, якщо він втикає ще 10 хвилий йде на техліда. Використовуємо alert manager (OpsGenie, PagerDuty, etc.) який гнучко конфігуруєтся, є пріорітети (прод, нон-прод), методи нотифікації (імейл, апка, смс, телефонний дзвінок).
Он-колл на тиждень, потім 3 тижні відпочиваеш.

звільнили техліда, який був відповідальний за проблеми на проекті в будь-який час доби

Я б тікав з компаніїї де такі процеси

проект у нас, до речі, досить новий, ще й року немає

В принципі все це ще може бути у процесі, може коштів не багато, щоб перенести проект на кубре в клауді щоб усе автоамтом, бо це час та гроші як мін на девопсів а іще не міграцію.

кубр з клаудом ніяк не відміняє необхідність онколлу.

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

В цілому реданденсі і авілабіліті то окремі практики(здебільошого девопсятина) і без автоматизації там ніяк. І клауд з кубером дуже сильно допомогають в цій автоматизації.

Звичайно допомагають, але не відміняють.
Уяви собі систему з мікросервісами, новий код в яких може іти на прод буквально кожень день і частина із яких ще має зовнішні інтеграції, і може залежати від них.
Іще додати залежність на декілька баз.
Ну і відповідно конфігурації кубера теж можуть змінюватися, в тому числі щоб пофіксити проблеми які вилізли під час онколу, щоб в наступний раз пофіксилося автоматично.

Для цього є архітектори та девопси, не мели маячню, чим більша система ти більше ріст онколу та супорту, для гівна, там не лінійний ріст ціни супорту.

А треті апішки, це взагалі перше про що думає архітектор, то як має вести себе система коли воно впало.

І головне питання, третя апішка впала, що може зробити онкол тєрпіла? написати на колінці гуглмапс за 2 години? чи фейсбук авторизацію? чи писати ліисти юезарм?

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

Це все закладається на початковому рівні, фолт толеранс, резистентність та авілабіліті.

Як що д ви заблии болт на це а проект має працювати 24/7 і це не перехідний єтап стартапу що виживає, то треба просто валити звідти, бо це тільки відбитий на голову сто/архітект заливає в прод глючне гівно і потім садить програміста фіксити це в ночі і віажає це нормальною практикою.

Ну і відповідно конфігурації кубера теж можуть змінюватися, в тому числі щоб пофіксити проблеми які вилізли під час онколу

в шо у вас є програмісти що тюнять кубер на проді в ночі? не сміши )))) ну і я хотів би послухати історію як тупий кубер упав, а програміст у три ночі підняв його за пару годин і пішов спати, або у вас згорів дата центр і цей самий програміст розглрнув продакшен кластер в новому датацентрі :-))))

У нас в команде такое есть — 3 человека по очереди дежурят(каждый по неделе). И я скажу — это довольно полезное занятие . Ты на свой сервис смотришь с другой стороны — все твои косяки вылазят. В этом ничего такого нет.

И я скажу — это довольно полезное занятие . Ты на свой сервис смотришь с другой стороны — все твои косяки вылазят. В этом ничего такого нет

Прекрасно.
А что на счет ошибок менеджмента, заложенного в сервис? (Я не про ваш кейс, а про кейсы галер и команд значительно крупнее). Сокращенные бюджеты? Незаапрувленные реальные эстимейты? Найм вместо 10 сениоров 4 сениоров и 6 джунов с последующей продажей всех как сениоров? Найм в ПМ-ы вместо профессионала любовницу или родственницу?
Эти все ошибки на качество сервиса и частоту on-call-ов не сказываются?

На галлерах критерии — продать больше людей и человеко/часов. Они иначе смотрят на ресурсы. Ну а с точки зрения девелопера — все просто. Довести свой сервис до продакшина, вылизать большинство багов благодаря on-call и если на тебя кладут болт — просто идешь в другое место с бОльшим багажем знаний. Никому эти нервы не надо...Но если с менежмента кто-то поймет, что при уходе чела на котором все держалось они потеряют проект — то разговор будет совсем другой.

С чего бы больший багаж знаний ? Допустим ты не знаешь например React. Идёшь по собеседованиям, а там поголовно в требованиях React и тех интервью с вопросами с подковырками, на которые можно ответить только имея практический опыт на фреймверке ? Как получить этот опыт и больше знаний, занимаясь багфиксом легаси на jQuery ? Ответ — никак, саппорт это кроме того что довольно напряжная деятельность ещё и гарантированная потеря квалификации. Да есть проекты которые постоянно развиваются и в состояние окаменелого гумна индийского мамонта никогда и не приходят. Такой проект надо искать или его делать, если нашелся хороший денежный заказчик.

А що ви там робите на тій лінії супорту як що не секрет? Чому автоматизація не може вирішити проблему супорту 24/7?

З недавнього:

Упало API стороннього сервісу для перевірки паролів юзерів. Через це жоден юзер не міг залогінитись в систему. Телефонували техліду в три години ночі.

Маркетологи створили акцію на 35к юзерів. В базу-то воно збереглось (всі юзери в json поле), але select для цієї таблиці вже не працював (не вистачало памʼяті для мускуля). Цей зламаний селект ламав важливу функціональність в системі.

Звичайно, після виявлення такі кейси фіксяться й оптимізуються (в основному, на рівні коду), але ж ніколи не знаєш, де і коли вилізе наступна проблема (проект у нас, до речі, досить новий, ще й року немає). Ще й один товариш з топ-менеджменту надто любить розводити паніку — колись о девʼятій годині вечора дзвонили техліду через непрацюючий staging сервер(

Тестування і планування.
Автомитизоване розгортання середовища
Продавани вороги, аби премію хапнути

Що це за юзери такі яким вночі не спиться?

ті, що знаходяться в іншій тайм зоні?

Всі 35к у компанії в Англії?

я так розумію що із-за якоїсь створенної акції перестав нормально працювати запит в базу, якийсь робився для кожного юзера. Не обов’язково всі 35к юзерів були активними в данний період.

Все правильно, так і було: запит працював для кожного юзера. Перевіряли, чи немає його в тому списку на 35к

Ще й один товариш з топ-менеджменту надто любить розводити паніку — колись о девʼятій годині вечора дзвонили техліду через непрацюючий staging сервер(

ось це вже не про абстракції, а про життя
в компанії може бути все інакше, але в конкретній зоні життя так як описано — я б шукав собі інше місце, як тут вже наводили приклад — іноді можна просто відмовитись з особистих причин і тобі знайдуть іншу тіму чи проект
як ні — ну то шукати іншу компанію, життя одне і якщо в першому регістрі вже не двійка — вночі треба нормально спати незалежно від всіх інших модифікаторів

Ой, так, доводилось працювати вночі в студентські роки — тяжко, навіть якщо тобі всього 21))) Досі та робота сниться.

Тобто у вас техлід закривав собою технічний супорт.
В мене було так
Перший рівень супорту — можуть створити тікет, перенаправити на інфру, допомогти юзерам почистити кеш і т.п.
Другий рівень — 24/7 в три зміни, технічні люди які можуть рестартнути сервіс, подивитись логи, мають список з частих проблем і їх вирішень. Можуть визначити чи це інфраструктура чи проблема апки, якій команді треба дзвонити.
Третій рівень — це дев команда.

У вашому випадку проект це дно. І спокою там не буде.

один з яких — чистий фронт, тому, його ставити в зміни немає сенсу

Занотуємо ще один плюс буди фронтом: тебе не ставлятимуть в наряди

Та нижче он люди і QA ставити пропонують, треба обговорити всі можливі варіанти з менеджером))

Тобто у вас кожен третій день чергування 24 години?? Якось жорстко

У нас це поки що на стадії обговорення. У колеги онколи прописані в контракті, в мене ні (ми з різних компаній). Я намагаюсь зрозуміти, який варіант є прийнятним для мене, бо в мене, як мінімум, тричі на тиждень спорт, тричі англійський, та й інших активностей вистачає. Потрібна гнучкість, мені навіть 24 години/зміна не варіант, не знаю, як люди тиждень в такому режимі працюють(

У колеги онколи прописані в контракті, в мене ні (ми з різних компаній).

Вы — ФОП. Изменить ваш контракт можно одним днём. Так же как и вашему коллеге-тимлиду сделают предложение, а дальше или соглашайся или досвидос.

Так
Але це вмикає додаткову оплату
Або гнучкий час як компенсацію

Делить на дежурства. Сегодня за это отвечает Вася, завтра — Петя, а скажем во вторник — Вы.
И он или она в эти сутки привязаны к рабочему месту, за что получают соот. плюшку.

Перша лінія онколу можетпросто тріажиьи проблемуиіишукати правильних людей.

Підтверждення так, за 15 хв
Потім ескалація

Коли я був на такому проекті, де нам запропонували добровільно-примусово чергувати 24 години on-call у мене тільки народилася перша дитина, я і без цього був на нервах. Я відмовився брати участь у цьому, і продовжував працювати як завжди. Через кілька тижнів мене кинули на бенч, а ще за кілька тижнів забрали з бенча на інший проект.
Але то були довоєнні часи, зараз я не відмовився б від страху втратити проект.

Команда у нас маленька, всього три дева, один з яких — чистий фронт, тому, його ставити в зміни немає сенсу.

Это не совсем так. Основная цель онколла это вернуть систему в рабочее состояние, не сделать фикс. Так что ранбуки + knowledge sharing + game days, и большинство инженеров с проекта могут быть онколл. У нас на одном проекте даже куашники брали шифты.

Який був графік змін (і скільки при цьому людей в команді)?

Пробовали шифты длиной в день и в неделю. Тут уж как команда договорится.

Чи був якийсь notice period дістатись до робочого місця?

Это всё должно быть формализовано и очень сильно зависит от системы. Условно говоря, 10-15 минут чтобы принять инцидент.

Доплати, компенсації?

Без этого онколл даже нет смысла обсуждать, без компенсации он не работает. У нас было на разных проектах либо процент от ЗП (грубо говоря, за каждый час онколла дежурный инженер получает какой-то процент от своей обычной почасовки), либо фиксированная сумма за шифт. Например 1к$ за неделю. + если инцидент вне рабочее время, то ещё время к отпуску. У нас было минимум + пол дня к отпуску. Если инцидент занимает много времени — больше отпуска.

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

Ну у дежурного инженера ноут всегда с собой должен быть. Так что да, можно и с супермаркета подключиться если что-то срочное) Но в целом всегда можно попробовать с кем-то из команды договориться.

Но да, 3 человека это очень мало. 1 ушёл в отпуск, второй заболел — вот и проблемы.

Це коли вам можуть зателефонувати в будь-який час , коли ви на чергуванні, а ви повинні бути готові приступити до роботи швидко (звичайно за 15-20 хвилин).

А якщо таки заснув? Чи там в гайді написано кожні 2 години пити енергетик?

Будуть телефонувати і, швидше за все, розбудять :) Попередньому техліду і в три години ночі телефонували, коли впав якийсь сторонній сервіс і юзери через це не могли залогінитись на сайті.

В телефоне звонки добавляются в исключения, если тихий режим на ночь включаешь)
В каноничном онколле есть основной дежурный, и 2-ой на случай эскалаций. Если первый забухал и не проснулся.

Так телефон розбудить.
Інша справа що назад засинати вночі можеш довше години

Нічим не можу допомогти, але чисто інтерес — це ЮС проект?

UK, головний офіс в Лондоні

Як варіант то перейти на Go

На Go конкуренція менша тому цінують фахівців більше

Аргумент, менший попит — але наростає, разом з тим меньша пропозиція. Go вже доріс до половини Java та .NET відповідно.

Тобто техлід був по суті на перманентному онколі? Не дивно що він звільнився :)
А запитати в нього не можна про умови онкола? Воно в різних компаніях буває по різному,як і умови, як і додатковий час на відпочинок, так і модель компенсація звичайно.

З техлідом у них зовсім негарно вийшло. Йому просто добряче недоплачували, а коли він серйозно підняв це питання, його компанія просто вирішила його звільнити. Але ми з ним в різних компаніях, в нього онколи були прописані в контракті, в мене немає.

Йому просто добряче недоплачували, а коли він серйозно підняв це питання, його компанія просто вирішила його звільнити.

Тут відповідь наче сама напрошується

В моїй уяві, якщо над кодом якогось проекта чи сервіса працює 3 людини, то онколл не повинен бути стресовим, якщо звичайно ці 3 людини кваліфіковані, і якщо це не стартап в якому кождень тиждень все заново переписується.
Онколл це ж не просто саппорт, це тільки для того щоб повернути непрацюючий сервіс в норму, якщо він перестав нормально працювати в нерабочий час.
Звичайно зовсім інша справа коли онкол на кодебазі над якою працюють 50+ людей, і ти навіть 20% змін не знаєш про що вони і де були, і кожен раз треба терміново і швидко розібратися де що могло завалитися. Хоча з досвідом і це теж вже не стає проблемою, якщо все ок з логами, моніторінгом, етц.

Это просто формальное скотство. Так как лид хорошо знал систему (наверно и кодил много сам )- на нем и ездили. Теперь это все переложили все на вас.

Компанія гівно без процесів.
Лід тряпка -ганчірка раз процес не побудував

Саме так воно і є. Буду підіймати питання, що дві людини — це надто мало для того, щоб покрити весь час. Або нехай шукають ще когось (бажано хоча б двох), або нехай будуть готові, що в якісь проміжки часу на зміні не буде нікого. Я прекрасно розумію ці приколи бізнесу, коли не хочеться шукати додаткових людей, якщо можна їздити на тому, хто є. Але так, мене такий варіант не влаштовує)

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

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

У нас було 15 хвилин, щоб відписатися що побачив і на скільке це критично. Як у вас, треба запитувати.

Компенсація — так була. Прийнято, що це фіксована сума, яка не залежить від ставки.

Тяжко це було суміщати з життям. Я їздив з ноутом завжди. Проблеми були майже кожен день. За пів року ми зменшили кількість таких проблем до одної на місяць. Але я на таке більше не підпишусь. Завжди голова забита тим, що може щось трапитись, а ти без інету.

Перш за все 3 людини — то дуже мало. Десь 4 треба, щоб один раз на місяць припадало чергування.

Дякую, що поділились. Техпідтримка є. Вони намагаються локалізувати проблему (third parties чи внутрішня), чи потрібно підключати IT, DBA і т.п. Але з девів, яких можна підключити, нас тільки двоє — і то, мій колега на проекті всього три місяці, багато чого не знає.
Так і думала, що в плані work-life balance це ще той головний біль(

Трохи почитав ще коментарії ваші. Онколл за життям ніяк не клеїться.
У онколла є 2 основних плюси.
1. Гроші. Дуже добрі гроші.
2. Починаєшь дуже добре розбиратися в тому, що відаєшь на прод. Доки пишешь, людей тренуєшь. На стендапах вже цікаво має бути після інциденту на онколі. Вже людина яка провели всю ніч за компом через те, що хтось накомітив без тестів — мовчати не буде.

Підписатись на коментарі