Tag: blameless postmortem

  • The Single-Sentence Postmortem

    The Single-Sentence Postmortem

    Do you have four seconds?  In the time it takes you to read this sentence you could be done with your incident’s postmortem.

    “But my postmortem has 8 sections!  I have to construct a critical timeline, restate my followup tasks, show the major milestones, evaluate root cause…”

    Stop right there.

    First of all, your incident management system should be automatically capturing your timeline, follow-up tasks and major milestones as they happen — so you shouldn’t be worrying about reproducing that content at all.

    Second of all, the most critical thing a responder can bring to a postmortem, in the moments right after the incident concludes, is the one-sentence personal context of what actually happened. It’s the same sentence they’d say to a co-worker in the lunch room when asked what went wrong. But to achieve organizational resilience, the knowledge in that sentence has to be captured and distributed. I can’t emphasize this enough – a single sentence can unlock 80% of the value. Writing something, anything, is so much better than writing nothing, and yet, too often, we see companies skip this part of the incident management process.

    Modern incident management, as a practice, was born on factory floors.  Instead of firing the person who was considered accountable for a major incident, having that person write up their view of what happened was more impactful at preventing future incidents. That’s because only the responder has the complete context to shed light on the contextual, systemic failures that actually caused incidents, as compared to the outside view of management and other employees who will often see problems as human-centered or due to obvious oversights (using 20/20 hindsight).

    When asked if he would fire an employee who made a $600,000 mistake at IBM, Thomas J. Watson famously replied, “No! I just spent $600,000 training him – why would I want somebody to hire his experience?”

    The reality is that any amount of your unique perspective as a responder is invaluable when compared to nothing, and without it, the chances of your company learning from these mistakes is slim. That’s why we encourage a unique approach: we tell our customers to spend four seconds on their postmortem.

    Especially for those new to incident response and management practices, it’s important to develop a practice of doing postmortems right away, as soon as the incident closes. As quickly as possible, open up your postmortem, jump to the ‘What Happened?’ section, and write one useful sentence. That’s it.

    Once you do that, we know that one of two things will happen:

    1) You’ll have other things to do, so you’ll publish the postmortem, and that one critical piece of knowledge will be shared throughout the company. That is infinitely better than nothing. 

    2) Or, you’ll realize you have more to say and get it done, right then and there.

    Like putting your running shoes on even if you don’t want to go for a run — at the very least, you’re up and active; at most, you’ll get out there and rack up some miles.

    Working with companies across industries and seeing thousands of incidents filed; hearing the stories of hundreds of companies’ incident management implementations has taught us that the alternative to a quick postmortem often isn’t often a more in-depth one, it’s no postmortem at all.

    So if you’ve just finished an incident– and if you’re about to pick up your coffee and move on to the next task at hand – instead, spend four seconds writing one sentence. It could make all the difference.

  • DevOps: What Do Governments Need to Know?

    DevOps: What Do Governments Need to Know?

    How the government can successfully implement and enforce DevOps practices

    The speed at which technology is being produced it outstripping the pace at which better development tools are being introduced, which makes secure development even more challenging. Unfortunately, the negligence of organizations and authorities is intensifying the issue.

    For this reason, organizations are adopting DevOps. for the betterment of technology. This way technology will be not only safe but also exciting to use.

    The term DevOps is derived from software development (Dev) and information technology operations (Ops), combined to create better results when separate groups work together as one team.

    What Can DevOps Do?

    DevOps has to manage the IT infrastructure as per the necessity of the recommended software code that is dedicated in a composite multi-tenant environment. There is a requirement to have the resources for provisioning, to get the suitable deployment model and also to authorize and monitor the performance.

    When DevOps is discussed, there is a requirement to have constant and incremental adjustments in the code versions so regular testing and deployment are possible. It might not always be feasible for DevOps to do coding from scratch, but they still must understand it.

    DevOps needs to connect several elements of coding and desegregate various segments of SQL data management or messaging tools to release the working software, with operating order and production infrastructure. It could be both the developers who started into operations and the system administrators who started into the coding domain. Either way, there is a cross-connection work function that is seeing a massive upside in the style of software that is produced and used in mission-critical applications.

    How Can DevOps Be Enforced Successfully?

    Now that we have discussed what DevOps do, it’s time to learn the ways in which organizations enforce DevOps successfully.

    Higher Authority

    It is essential that we refer to higher authorities. By getting support from the top authorities, we can easily manage the work of DevOps.

    “DevOps is fundamentally a reorganization.”

    –Adrian Cockroft, lead architect, Netflix

    Altering any management organization, with its deeply rooted techniques of functioning and complicated network of employees and suppliers, is a challenging job. So, solid backing at the beginning is as crucial as having employees. You cannot start a new technique without employee support; in the same way, you cannot begin a new plan without any support from authorities. You need someone from the top to monitor the work and provide feedback.

    Blameless Postmortem

    Adopting DevOps also requires every member of the team be comfortable in their learning. Hence, the blameless postmortem, which eliminates finger-pointing when things go wrong—highly recommended for DevOps beginners. Blameless postmortems are even required by some government offices.

    Blameless postmortems organize a cross-section of those invested in the project to evaluate why certain outcomes occurred. The postmortems include an examination of the situation and ways to resolve them through various procedures or technology variations. They are an excellent method to initiate constant development.

    Increase DevOps Engineers

    Another effective way of expanding DevOps and enforcing it in the government is through hiring DevOps engineers. A DevOps engineer is the individual responsible for all the steps during the process of DevOps, and are responsible for bringing both organizations together to work as a team. There are not enough DevOps engineers today and the workload is much more than they can handle.

    Start Small and Scale Up

    Whenever you start something new, start on a smaller scale. Whether you’re working on a business plan or testing a new recipe, you should always start small and work your way up.

    In the same vein, it is important to start small when implementing DevOps. Rather than go all-in at once, create a group of people who will work together as a team. If the results are good enough, then expand your implementations to a wider audience.

    Eliminate Restrictions

    Last but not least, it is essential to remove all the constraints involved. Eliminate any limitation that may occur during DevOps enforcement. Limitations could vary from generating new constructions or applying code variations to assimilating data foundations. If the constraints are not removed from the beginning, it may cause problems afterward.

    Conclusion

    With the expansion of equipment and expertise, new practices are introduced in the government. If applied properly, these practices could generate pleasant outcomes. DevOps, which brings together two forces for effective results, is one such practice.

    — Zehra Ali