On-call зміни

Karina Kosenko PHP developer в IT Craft 29.03.2024 19:44

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

Gremlin

Gremlin 30.03.2024 10:21

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

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

Vitalii Senior DevOps в Customertimes 11.08.2023 14:06

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

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

Uncle Bob 08.08.2023 11:37

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

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

Учасник 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; ну хоче замовник, чому б ні.

Просто Анон 09.08.2023 11:32

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

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

Uncle Bob

Uncle Bob 09.08.2023 20:18

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

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

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

P.S Little update

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

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

Andy K 09.08.2023 20:37

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

Uncle Bob

Anton Pavlovich 08.08.2023 10:32

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

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

Dmytro Vynokurov Engineer 07.08.2023 22:09

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

Alex Bylim 07.08.2023 19:23

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

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

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

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

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

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

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

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

Ювженко Денис System Architect в Intellias 07.08.2023 16:44

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

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 17:33

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

Ювженко Денис System Architect в Intellias 07.08.2023 19:49

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 20:20

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

Ювженко Денис System Architect в Intellias 07.08.2023 20:35

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

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

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 21:00

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

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

Ювженко Денис System Architect в Intellias 07.08.2023 22:41

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

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

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 23:03

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

Otak 08.08.2023 11:42

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

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

Bot Bot 08.08.2023 00:00

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

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

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

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 00:23

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

Bot Bot

Bot Bot 08.08.2023 00:40

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

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

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 00:49

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

Bot Bot

Bot Bot 08.08.2023 00:51

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

Bot Bot 08.08.2023 01:40

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

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 09:40

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

Bot Bot

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 00:51

А шо пацани в три ночі пишуть заміну серд паті сервісу?

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

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.

Bot Bot

Bot Bot 08.08.2023 00:56

Communication: Inform relevant stakeholders

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

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

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 01:31

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

Bot Bot

Bot Bot 08.08.2023 00:04

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

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

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

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

Bot Bot 07.08.2023 23:58

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

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 00:34

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

Bot Bot

Bot Bot 08.08.2023 00:44

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

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

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

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

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

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

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

Sеrgejs Bоrуsson Senior Tractorist 08.08.2023 00:56

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

Bot Bot

Gena Kartashevskyy Platform Engineer в MyHeritage 08.08.2023 12:46

В Амазоні і Гуглі деви онколл на додачу до 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 заюзати )

Bot Bot

Bot Bot 09.08.2023 00:45

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

Gena Kartashevskyy

Otak 08.08.2023 11:37

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

Vic Programmer 07.08.2023 20:27

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

Ювженко Денис System Architect в Intellias 07.08.2023 20:42

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

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

Vic

Vic Programmer 07.08.2023 20:56

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

anonymous 08.08.2023 02:01

-

Otak 08.08.2023 11:36

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

Olena Sharovar Senior Software Engineer (Billing) in a startup 07.08.2023 15:07

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

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

Vic Programmer 07.08.2023 20:37

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

Полная трехмерная копия Юры Буряка 09.08.2023 00:40

Olena Sharovar

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

Olena Sharovar

anonymous 07.08.2023 15:00

-

Vic Programmer 07.08.2023 20:40

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

anonymous

anonymous 07.08.2023 20:52

-

Vic

осокор тауер 07.08.2023 13:56

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

Віталій Мартиник Senior Software Engineer в United Software 07.08.2023 15:20

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

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

осокор тауер 07.08.2023 17:40

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

Віталій Мартиник

Просто Анон 07.08.2023 18:56

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

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 19:00

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

Просто Анон 07.08.2023 21:37

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 22:08

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

Просто Анон 08.08.2023 11:12

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

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

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

Karina Kosenko PHP developer в IT Craft 08.08.2023 11:25

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

осокор тауер 07.08.2023 17:42

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

Volodimir Nazarenko Senior .Net Developer / Teamlead в Perfectial 07.08.2023 13:44

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

Vic Programmer 07.08.2023 13:37

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 13:50

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

Vic

Vic Programmer 07.08.2023 14:00

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

Viktor Zhurbenko Dev 07.08.2023 15:26

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

Віталій Мартиник Senior Software Engineer в United Software 07.08.2023 15:48

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

Viktor Zhurbenko

Vic Programmer 07.08.2023 21:34

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

Viktor Zhurbenko

Viktor Zhurbenko Dev 07.08.2023 22:17

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

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

Vic

anonymous 07.08.2023 13:21

-

Vic Programmer 07.08.2023 13:41

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

anonymous

Philip Pristupa 07.08.2023 13:45

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

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

Vic

Karina Kosenko PHP developer в IT Craft 07.08.2023 13:47

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

Philip Pristupa 07.08.2023 13:49

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 13:56

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

anonymous 07.08.2023 15:02

-

Vic Programmer 07.08.2023 13:54

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

Vic Programmer 07.08.2023 14:30

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

Vic

Andrii Striletskyi DevOps в Deloitte 07.08.2023 13:09

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

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

Andrii Striletskyi DevOps в Deloitte 07.08.2023 13:28

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

Andrii Striletskyi

Віталій Мартиник Senior Software Engineer в United Software 07.08.2023 15:22

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

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

Andrii Striletskyi

Invisible insider 07.08.2023 12:05

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

Nikita Podgorbunskyi Software Engineer в безмежних просторах цифрових технологій 07.08.2023 12:02

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

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

Valentin Nechayev уповноважений по милицях в Дарницькі печери 07.08.2023 13:45

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

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

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

Nikita Podgorbunskyi

Олег Высоцкий 07.08.2023 11:50

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

Melnyczenko Mel 07.08.2023 11:34

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

to1 to1 07.08.2023 10:45

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

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

Олег Высоцкий 07.08.2023 11:43

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

to1 to1

to1 to1 07.08.2023 11:50

Добре. Ось інша стаття:
wiki.legalaid.gov.ua/..._тривалості_робочого_часу
Підходить?

Олег Высоцкий 07.08.2023 11:55

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

to1 to1

to1 to1 07.08.2023 12:08

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

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

Dmytry Ginzburg 07.08.2023 15:50

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

Serge Loboda Senior Software Developer в Access Softek, Inc. 07.08.2023 12:41

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

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 12:44

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

Serge Loboda

Philip Pristupa 07.08.2023 13:56

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

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

to1 to1 07.08.2023 14:15

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 14:20

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

Sergei Beloborodov blockchain dev 07.08.2023 15:15

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

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 15:24

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

Sergei Beloborodov

Sergei Beloborodov blockchain dev 07.08.2023 15:26

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

Vic Programmer 07.08.2023 21:25

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

Руслан Молодик 07.08.2023 10:09

За онколи доплачують? О_О

Вавилен Татарский 07.08.2023 11:19

В нормальних місцях — так.

Руслан Молодик

anonymous 07.08.2023 12:48

-

Вавилен Татарский

Vic Programmer 07.08.2023 13:36

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

anonymous

anonymous 07.08.2023 13:54

-

Vic

осокор тауер 07.08.2023 13:47

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

anonymous

Михаил Дьяченко Delivery Manager в Capgemini Engineering 07.08.2023 13:47

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

anonymous

Вавилен Татарский 07.08.2023 15:19

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

anonymous

Roman Tretyak QA Automation в Ciklum 08.08.2023 14:18

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

anonymous

anonymous 08.08.2023 14:29

-

Roman Tretyak

Олег Гончар 07.08.2023 09:32

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

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

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

осокор тауер 07.08.2023 10:48

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

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

Олег Гончар

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 10:58

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

Valentin Nechayev уповноважений по милицях в Дарницькі печери 07.08.2023 13:22

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

Просто Анон 07.08.2023 09:30

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

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

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

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

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

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

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

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

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

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

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

Igor Yatsenko 07.08.2023 09:05

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

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

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

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

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 09:14

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

Igor Yatsenko

Просто Анон 07.08.2023 09:59

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

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

Полная трехмерная копия Юры Буряка 07.08.2023 11:05

Igor Yatsenko

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

Philip Pristupa 07.08.2023 14:56

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

Полная трехмерная копия Юры Буряка 07.08.2023 01:31

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

осокор тауер 07.08.2023 10:56

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

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

Полная трехмерная копия Юры Буряка

Полная трехмерная копия Юры Буряка 07.08.2023 11:07

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

осокор тауер 07.08.2023 13:49

blog.pragmaticengineer.com/oncall-compensation
Можливо інфа не найновіша правда, не певен.

Полная трехмерная копия Юры Буряка

Volodimir Nazarenko Senior .Net Developer / Teamlead в Perfectial 07.08.2023 14:00

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

Полная трехмерная копия Юры Буряка

Олег Front End Lead 07.08.2023 01:27

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

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

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

Melnyczenko Mel 07.08.2023 11:38

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

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

Олег

Олег Front End Lead 07.08.2023 13:49

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

Melnyczenko Mel

Kostya Novak 07.08.2023 01:04

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

Рахіт Срінавасович Кумар 07.08.2023 02:52

Вони тупі
Це 2й рівень

Kostya Novak

Volodymyr Fesenko 07.08.2023 00:44

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

Рахіт Срінавасович Кумар 07.08.2023 00:17

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

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

Bot Bot 07.08.2023 00:24

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

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

Рахіт Срінавасович Кумар

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 00:37

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

Bot Bot

Bot Bot 07.08.2023 02:34

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

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 07:41

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

Bot Bot

Bot Bot 08.08.2023 00:19

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

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

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

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

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

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

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

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

Oleg Artyomov Java Tech Lead в Intapp 06.08.2023 22:59

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

Philip Pristupa 07.08.2023 15:02

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

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

Oleg Artyomov Java Tech Lead в Intapp 07.08.2023 16:58

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

Vic Programmer 07.08.2023 21:19

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

Bot Bot 06.08.2023 22:31

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 22:47

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

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

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

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

Bot Bot

Bot Bot 06.08.2023 22:50

Дякую, зрозуміло.

Рахіт Срінавасович Кумар 07.08.2023 00:18

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

Віталій Мартиник Senior Software Engineer в United Software 07.08.2023 10:49

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 11:05

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

Віталій Мартиник

Віталій Мартиник Senior Software Engineer в United Software 07.08.2023 11:25

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

Sеrgejs Bоrуsson Senior Tractorist 07.08.2023 11:57

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

Віталій Мартиник

Karina Kosenko PHP developer в IT Craft 07.08.2023 12:01

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

Prairie Marksman 07.08.2023 11:45

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

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 11:53

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

Prairie Marksman

Просто Анон 07.08.2023 12:36

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

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

Taras 06.08.2023 22:13

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

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 22:17

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

Taras

Max Skorik 06.08.2023 21:53

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 22:15

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

Max Skorik

Рахіт Срінавасович Кумар 07.08.2023 00:20

Потім тиждень шаряться

Philip Pristupa 07.08.2023 15:04

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

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

Рахіт Срінавасович Кумар 06.08.2023 21:47

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

Dmitry 06.08.2023 20:43

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

Рахіт Срінавасович Кумар 06.08.2023 21:48

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

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

Dmitry

johnwalsh1 06.08.2023 20:19

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

Пять холодильников 06.08.2023 20:11

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

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

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

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

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

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

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

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

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

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

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

Max Max 06.08.2023 20:02

Шо таке он колл ?

Karina Kosenko PHP developer в IT Craft 06.08.2023 20:03

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

Max Max

Max Max 06.08.2023 20:46

Ясно
Танунах

Max Skorik 06.08.2023 21:50

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 22:11

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

Max Skorik

Пять холодильников 06.08.2023 22:15

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

Max Skorik

Рахіт Срінавасович Кумар 07.08.2023 00:21

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

Max Skorik

Bohdan Demydov 06.08.2023 19:57

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 20:00

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

Bohdan Demydov

Ярослав Характерник Golang Developer в DocHQ 06.08.2023 19:47

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

anonymous 07.08.2023 01:46

-

Ярослав Характерник

Ярослав Характерник Golang Developer в DocHQ 07.08.2023 02:23

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

anonymous

Vic Programmer 07.08.2023 21:08

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

Ярослав Характерник

Sеrgejs Bоrуsson Senior Tractorist 06.08.2023 19:47

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 20:00

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

Maxim Deyneka Software Engineer 06.08.2023 21:08

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

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

Sеrgejs Bоrуsson Senior Tractorist 06.08.2023 21:25

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

Oleg Artyomov Java Tech Lead в Intapp 06.08.2023 23:03

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

Рахіт Срінавасович Кумар 07.08.2023 00:22

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

Karina Kosenko PHP developer в IT Craft 07.08.2023 09:03

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

Konstantin Strukov 07.08.2023 18:07

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

Viktor Syrovets 06.08.2023 19:47

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

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

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

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

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

Karina Kosenko PHP developer в IT Craft 06.08.2023 19:55

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

Viktor Syrovets

Viktor Syrovets 07.08.2023 09:53

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