VictorOps is now Splunk On-Call! Learn More.

The DevOps Dictionary (Part Two)


We’re back with more of The DevOps Dictionary, a list of the most important terms and DevOps definitions. Part One covered letters A-I, and part two now continues with letters J-O. The final letters, P-Z, will be covered in part three.


“Merging is the process of taking two or more groups of data and combining the data into a single unified set. Generic merging (like that done with the MS-DOS copy command) takes one or more files and combines them into one file. More advanced merging commands and programs are capable of only merging data that is new or updated to a file.” (Computer Hope)


“Traditional monitoring includes monitoring low-level items like CPU, memory, and disk utilization. It is still important to understand and have data for these things as they will help with capacity planning and may be helpful data points when responding to incidents and outages. - DevOps and Monitoring, Nov. 2017 - Nathan Harvey”

“With DevOps, continuous integration (CI), and continuous delivery (CD), monitoring needs to level up and include all aspects of a system. Being able to monitor software as it’s being created, implemented, and after it’s in production is essential. Focus your monitoring tools on tracking the infrastructure and code base.”

“Monitoring your infrastructure means analyzing your servers, containers, and any other network devices for trends or problems.”

“DevOps monitoring has advanced beyond monitoring your systems with CI/CD tools. It’s time you push forward and insist on the information and alerts from all of your tools being visible on one platform. You need to visualize everything happening and learn from application trends.” (Amanda Boughey, VictorOps)

“‘Monitoring’ is the word you use when talking about tools for viewing data that has been recorded by your systems (whether that be time series data, or logging etc). These monitoring tools are supposed to help you identify both the ‘what’ and the ‘why’ something has gone wrong.” (Observability and Monitoring Best Practices)

MTTA (Mean Time to Acknowledge)

MTTA (Mean Time to Acknowledge) is a measurement used to track the average time it takes to acknowledge incidents. With an MTTA report, you can track goals over time and tell key stakeholders the story by relaying key metrics directly related to the cost of downtime.


“We all agree the MTTR (mean time to repair/resolve) metric is core to any Incident Management practice. Teams who focus on reducing Mean Time To Repair (MTTR) rightly focus heavily on the Remediation phase.” (Matthew Boeckman, VictorOps)


“A node is either a redistribution point or a communication endpoint. The definition of a node depends on the network and protocol layer referred to. A physical network node is an active electronic device that is attached to a network, and is capable of creating, receiving, or transmitting information over a communications channel. A passive distribution point such as a distribution frame or patch panel is consequently not a node.” (Wikipedia)


“In general, observability is a property that you need to engineer in a system from day one. The thing most experts can agree on is that to achieve basic observability, you need to have metrics, logs, and tracing. Essentially, if you can combine those three things, then you have a system that is observable. In my mind, you can’t do monitoring without observability. As far as design goes, people who are using CI/CD systems would ideally have dashboards or visibility as soon as they deploy new code and would be able to look at it and agree that everything is okay. - Paul, CTO at InfluxData.”

“There are two things that we are doing to support observability within our platform. Observability within our platform means one of two things. One, bubbling up that information and two, making it relevant in the context that you need it. To us, taking the data and making it relevant is more about answering the question, what are they going to be doing next? - Drew McKinney, UX Designer at VictorOps.”

“Design in observability enhances how metric gathering systems work and focuses on providing valuable context to the systems for everyone in the organization. We, as an industry, could always use more of this.” (Hannah Klemme, VictorOps)

“It’s a world where we not only have the necessary information for troubleshooting and debugging, but also a detailed understanding of how the running system is performing–with alerts for when things go wrong.” (Jonathan Schwietert, VictorOps)

“Observability” is the word you use when talking about how well your systems are doing in a broad overarching sense (is the system observable?). Beneath the umbrella term ‘observability’ we’ll then find ‘monitoring’ and ‘instrumentation’.” (Observability and Monitoring Best Practices)

Open source

The advent of the open source movement changed the rules of the game. It was now possible for developers to leverage the work done by others, rather than reinventing the wheel over and over again. The other, possibly more important benefit is that because the source code is open, it can be reviewed and improved by the community (often including experts in a particular field) and everyone benefits.”

“Open source created a revolution in software development and has helped fuel the ever-increasing pace of innovation in the technology industry.” (Bryce Ambraziunas, VictorOps)

Ops (Operations)

“At VictorOps, we often refer to our support team as Ops. However, the term is actually associated with Operations teams. Thus: Dev - Ops. Operations teams are historically the ones who manage production environments. Synonyms can be system administrators, site reliability engineers, production engineers and more. In general, when you hear someone talk about Ops, they are not referring to the development team but rather the ones responsible for provisioning and managing infrastructure as well as the ‘running’ application.”

“Through DevOps, this paradigm is shifting and developers of all kinds now build, support, and operate the system both during the development phase as well as in production.” (Tara Calihman, VictorOps)


“On-premise software is installed and runs on computers on the premises (in the building) of the person or organization using the software, rather than at a remote facility such as a server farm or cloud. On-premise software is sometimes referred to as ‘shrinkwrap’ software, and off-premise software is commonly called ‘software as a service’ (SaaS) or ‘cloud computing.’” (Wikipedia)

Don’t forget to check out parts one and three of The DevOps Dictionary as well:

Let's Make On Call Suck Less...

Let us help you make on-call suck less.

Get Started Now