Before the philosophy of DevOps, developers would build products, services, and infrastructures , but the responsibility for maintaining them would shift to operators, aka system or IT admins. The DevOps philosophy removes the boundary between Operations and Development teams, making system reliability a shared responsibility of all parties.
One of the trends we at OpsGenie are observing is that incident response teams are becoming more complex. They can be widely distributed, made up of different levels of employees, and can even have contractors and temporary employees as members. Greater flexibility is needed when assigning permissions and access rights.
Incident response is the process of identifying, investigating, and responding to the issues and events that disrupt or have the potential to disrupt normal service operation. There are a handful of universal challenges with which almost every incident response team struggles. Addressing these common problems can help organizations reduce their incident resolution times, minimize cost, and prevent decay of their company’s reputation. In this post, we take a look at five of the most common of these problems.
You spend time creating your OpsGenie configuration, so it’s now crucial to ensure that your account configuration is safe and reproducible just in case something goes wrong.
Git is a distributed version control system that records changes to a file or set of files over time. This allows tracking changes to each file and recalling a specific version later. It’s primarily used by developers as a source code management system; however, it can and should be utilized in Operations, too. Git is efficient for not just code, but also for all kinds of alternative files such as configuration files.
Earlier, OpsGenie introduced the new “OpsGenie Configuration Management Tool.” This tool uses OpsGenie Java SDK to export OpsGenie configurations as JSON files enabling customers to take advantage of Git to manage the configuration data. Got that? The tool also supports restoring configurations, which means that it not only tracks configuration changes, but also reverts to a previous configuration if needed.