Comments 2
Я верно понял, что всё вышеописанное относится скорее к Site Reliability инженерам, ежели, чем, например, к стаффу саппорта любого вендора ПО?
0
С одной стороны — да, на примере SRE всё описанное раскрывается ярче всего, а с другой стороны принципиальной разницы нет. Приведу пример: если вы занимаетесь разработкой игр, и у вас на запуске игры у персонажей не отрисовываются кожные покровы, и по итогу об этом судачит весь Интернет и всё завалено мемасами, то это вполне себе major incident и было бы бесконечно глупо повторить такую же ошибку при выпуске следующей игры на этом же движке. Так что практика разбора и формулирования action points тут уместны. Саппорт-инженеры, даже целые support-команды практикуются в самых разных it-related областях.
Ну и даже если вы поставляете оффлайновый софт для пары подрядчиков, и он время от времени ломается на рабочих станциях отдельных сотрудников, то всё равно придется эти баги сортировать по приоритетности, решать, кто какую возьмёт и так далее.
Ну и даже если вы поставляете оффлайновый софт для пары подрядчиков, и он время от времени ломается на рабочих станциях отдельных сотрудников, то всё равно придется эти баги сортировать по приоритетности, решать, кто какую возьмёт и так далее.
+1
Sign up to leave a comment.
Танцы с саппортом: виды и формы поддержки. Саппорт систем, работающих в бою