ITIL : Developer’s Worst Nightmare ?

A developer is a person for which his/her code is like a treasure or a baby. Most of the developers are very much serious about their coding, whether he/she is fresher or 10-15 years experience person. In India, we hardly see a developer who is having 10 or 15 years experience in coding. If we find any such person then he/she will be like hardcore coder as the corporate practice doesn’t provide career growth after certain years on the technical side. They must choose a managerial option for further growth.

Anyways coming back to topic what can be developer’s worst nightmare? breakup with the girlfriend? Getting sacked? Appraisal ? Code not getting committed?  Incorrect requirement? I think the one I have seen in my lifetime is when code fails on production and on other side works perfectly fine in every single environment. Most of the techies come with the reason that code is working on dev/test/UAT environments. But from a production perspective, working code in any other environment but not in production holds no value and results in the back out.

To avoid such situations developers needs to go beyond their component scope by understanding the production environment needs domain requirements, system architecture/versions/bugs. Another important factor is the load, in large production environments, most of the times due to lack of performance testing code fails to sustain against high customer load. Also sometimes to parallel user stories delivered at the times can cause the problem with each other due to common services they are using during their journey cycle.There can be many such scenarios. But definitely understanding production scope and working will definitely reduce the likelihood of code failure. 🙂

Advertisements

ITIL – Incident Closure/Problem Record when no workaround ?

As per the ITIL framework, Incident record used for auditing purpose for tracking production issues. Depending on the impact on services Incident Record can have different priorities and resolution times as per the defined SLAs.

Standard practice says that incident can only be closed when impacted service is restored. Some companies follow the strict practice of tagging every single incident to the PM record for RCA. Ideally, from my view for the one-off incident should be considered as out of scope for problem management. The definition of Problem says an Unknown fault with the service/application which needs root cause analysis followed by the permanent fix. Therefore, to summarize problem records are the mandatory parameter for delivering in-life fixes discovered via incident management route. Except proactive problem management which helps to resolve fault in live service which hasn’t caused service impact.

Coming back to Incident resolution what if we don’t have the workaround. A workaround is set of activities Support team performs as part of the temporary fix to restore service. So, in this case, we cannot close this incident since service is not restored and problem record can only be raised when the incident is service restored leaving catch-22 situation. The solution to this is to leave Incident Open and deliver permanent fix under incident without creating problem record followed by service restoration.