%20%D0%B2%20%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%B5%20%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B9%20%D0%B3%D1%80%D1%83%D0%BF%D0%BF%D1%8B%3F.png)
и измеряете ли вы его вообще?
Моя проблема в том, что когда появляется оповещение о сбое, кажется пустой тратой времени сначала создавать тикет JIRA, поэтому я начинаю решать его сразу. Кроме того, некоторые сбои сначала решаются обходными путями, а затем возвращаются к ним, чтобы решить их должным образом.
решение1
«Моя проблема в том, что когда приходит оповещение о сбое, кажется, что сначала тратится время на создание тикета JIRA»
Конечно, это легко решается: большинство систем оповещения могут выдавать несколько оповещений одновременно, и одним из таких оповещений может быть автоматическое создание тикета Jira.
Частью закрытия тикета Jira может затем стать административная задача по регистрации (любым удобным для вас способом/системой) согласованного вами времени ремонта.
(Это уже подразумевалось, но позвольте мне заявить об этом прямо: время разрешения тикета, отслеживаемое вашей системой тикетов, не совпадает со временем на ремонт.)
Когда время разрешения тикета важно и является показателем производительности, вы можете закрыть автоматически созданный тикет для сбоя сразу после его устранения.
Когда вы начинаете расследование анализа первопричин (RCA), используйте связанный, но новый тикет для расследования проблемы #XYZ (который имеет другие критерии производительности и сообщается иначе, чем тикеты, касающиеся сбоев).
В зависимости от результатов RCA вы можете начать работу над постоянным исправлением/мерами по смягчению последствий, которые вы будете отслеживать по-другому, в зависимости от того, что необходимо сделать.