Співбесіда DevOps і SRE — це не про перелік інструментів, а про рішення в умовах обмежень: що відкочувати першим, на що ставити алерт і що свідомо лишити зламаним до ранку. Нижче — питання, які ставлять найчастіше, кожне з еталонною відповіддю. Senior: архітектуру, трейд-офи, менторство та прийняття рішень.
Зробивши кожен деплой оборотним незалежно, а це здебільшого обмежує базу: розширювати до звуження, ніколи не видаляти в тому ж релізі, у якому припинили писати. Друга вимога — відкат має використовуватися: шлях, який проходять раз на квартал під час інциденту, це шлях, який не працює. Фіче-прапорці розводять реліз і деплой і перетворюють більшість відкатів на правку конфігурації.
Спершу відновити сервіс, діагностувати другим: відкат, переведення трафіку чи масштабування не потребують знання першопричини. Хтось володіє координацією і при цьому сам не налагоджує, а хронологія пишеться по ходу, бо памʼять потім відновлює її неправильно. Розбір питає, що зробило відмову можливою і що зробило її довго непоміченою, а не хто набрав команду.
На симптоми, які відчуває користувач: частку помилок, затримку, недоступність, — а не на причини, бо причин багато і більшість нешкідливі. У кожного алерта має бути дія; той, який регулярно підтверджують і ігнорують, навчає людей ігнорувати алерти. Міра якості — скільки спрацювань були зайвими, і це число треба регулярно дивитися.
Спершу на requests проти фактичного споживання, бо завищені requests резервують потужність, якою ніхто не користується, і це найбільше джерело втрат. Далі на розмір вузлів і пакування, далі на те, що працює і нікому не належить: старі середовища, забуті балансувальники, знімки. Сховище і вихідний трафік — рядки, що ростуть тихо і ніколи не потрапляють у першу оцінку.
Імпортуючи, а не перестворюючи, по одному обмеженому шматку, починаючи з малоризикового, щоб процес обкатався до того, як стане важливим. Труднощі не в інструменті, а в правилі, що ручні правки припиняються: код, що розійшовся з реальністю, гірший за відсутність коду — йому довіряють, і він хибний. Перевірку розбіжностей треба запускати за розкладом.
Ставлячись до кількості спрацювань як до числа дефектів із власником, а не як до погоди. Ротація, що будить ночами, випалює людей, і плинність обходиться дорожче за інженерний час на усунення причин. Конкретні практики: задача-наслідок з кожного спрацювання, стеля допустимої рутини і час у наступному спринті, зарезервований під те, що розкрило минуле чергування.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Senior DevOps / SRE →