Flow of On-call Policy(Deprecated(only this page))
What is the purpose of the Article?
You will understand about how the on-call policy works in Eshopbox.
Audience
Software Development Engineers
Project Managers
Support Teams of Bug reporting channels
Flow Diagram:
Here’s a breakdown of the above on-call policy flow and what all the on-call developers need to do:
A Bug is reported to Eshopbox from one of its various support channels
The concerned Support team person would check the Status Page of the company to ensure whether the Bug reported is an existing one or a new one.
If it is an existing Bug, the concerned support team person would notify the same to the complainant through the support channel.
Else, the Bug would be created by the support team person under the “Bugs” project in Jira either directly or through intercom integration.
After the support team person has created the issue in the “BUGS” project, an email will be received by everybody. Those who are on-call at present need to immediately acknowledge the issue(within 10 minutes during working hours) by assigning any 2 from the 5 on-call person from the 4 groups as Assignee and the Reporter. All the on-call persons will also comment “acknowledged” in the comments sections separately.
The on-call persons would then analyse the Bug, in which the first step involves identifying whether the issue reported is a Bug or not in actual:
If it is not a bug then,
If it is a configuration error from the complainant’s end, inform the same to the complainant and provide steps to rectify the same(Send an email with a detailed explanation and corrective measures), through the support team of the channel on which the Bug was reported.
If it is a limitation of the current feature/functionality, inform the same to the complainant(Send an email with a detailed explanation) and if possible, with a timeline as to when this limitation would be resolved, through the support team of the channel on which the Bug was reported.
Else, inform the support team that the issue reported is not a Bug at all(Send an email for the same) and the behavior is as expected. The support team of the channel on which the Bug was reported will inform the same to the complainant.
YOU MUST BE ABSOLUTELY SURE BEFORE MARKING AN ISSUE AS NOT A BUG. For this you may check with the concerned developer(SDE-II) before taking the final decision.
If it is a bug then
Identify whether it is a Bug from the Frontend or Backend Team
Assign a Priority to the Bug
Report on the Status Page ,depending upon its priority, that a Bug has been found and is under investigation(contact @Akshay Aggarwal (Unlicensed) in case of assistance needed)
Send an email on oncallsupport@eshopbox.com that the reported issue is a BUG and can now be tracked from the status page(https://eshopbox.statuspage.io/).(only when reported on Status Page)
Is the on-call person able to resolve the Bug:
If YES, then the on-call person will look for the solution in the Run-book of the project to which this Bug is related and proceed accordingly
If NO, then the on-call person will assign the Bug to the concerned developer who will be able to resolve the Bug. The reporter in Jira for this Bug would be the current On-call person(backend or frontend depending upon whether the Bug is of frontend or backend).
It is the responsibility of the on-call persons to make sure that the concerned developer is aware about the issue and is also required to contact him/her if needed.(Contact details available here)
The concerned developer will analyse the Bug assigned to him/her:
If it is not a Bug according to the developer then the developer will notify the on-call person about it, who will update the support team and the Status Page.
If it is a Bug, then proceed towards resolving the Bug within its TAT(turn around time), and deploying the changes, as per the priority assigned to the Bug.
After the Bug has been resolved the concerned developer who resolved the Bug will update the current on-call person and the on-call person will update the Status Page and the Run-book, if required, for that particular project.
As an on-call developer it is your responsibility to make sure that the BUG reaches the “Resolved” status and the correct status is displayed at all times against the BUG. In other words you are accountable for status transitions of the BUG at all times.
Developers it is also your responsibility to ensure that the BUG reflects “Resolved” status after you have resolved it. Otherwise it will be counted as a Resolution TAT breach against you if the status is not changed within the TAT even after you have resolved the BUG.