Skip to main content - The eBook-Shop with Checklists and Templates for Professionals
Skip main navigation
Template Systems Operations ManualTemplate Data Centre Operations ManualData Migration ChecklistNonfunctional RequirementsInterface (EAI) Checklist Server Upgrade / Migration ChecklistApplication Upgrade / Migration ChecklistApplication & Server Inventory TemplateRelease ChecklistOutage PlanningApplication CloningApplication RetirementApplication Health checkArchiving RequirementsDisaster Recovery (DR) Technology SelectionBackup OLA / SLADatabase OLA / SLADBA Job DescriptionDatabase Health Check
DevOps Application Support Data Migration OLA / SLA Operations Level AgreementSystem DocumentationProject ManagementDeploymentQuality AssuranceCompliance and StandardsDatabase Administration Start-up Phase Achieving Operational Readiness Stabilized Operations

Checklists and Tempates for DevOps

What is DevOps?

The Dilemma

  • Operations is the longest and most important phase in an applications life cycle.
  • But requirements for this phase get the least attention.
  • Operational Requirements are the step children of requirements engineering and development.

The Answer

DevOps brings operational competency into the development team to facilitate the delivery of easy to operate, reliable and resilient applications.


The usual Situation without DevOps The Benefit - How DevOps addresses those issues:
Complex, manual installation process requires high deployment effort on each test and production system. Fully scripted installation. DevOps staff is highly skilled in using professional tools to facilitate fully automated deployment.
This eliminates human errors, reduces planned downtime for upgrades and facilitates Continuous Integration and Continuous Delivery.
The system is very difficult to operate The DevOps member takes care that within
  • Requirements specification phase (Waterfall) or
  • Sprint Planning Meeting #2 (Agile)
    • the non-functional requirements for operability get sufficient attention in the specifications.
Troubleshooting is difficult, because of insufficient log file information and trace functionalities DevOps member will support developers in implement sufficient looging- and tracing functionalities, e.g. by using logging frameworks.
At overload or other disturbances application crashes or hangs up, requiring restart DevOps will help to build resilience into the applications code.
It is impossible to meet SLA's desired by business with application as delivered. DevOps member will take care that SLA's are known before, and that operational requirements are specified and implemented such that the SLA's can be met.
No or incomplete Operations Manual (Runbook) The Operations Manual (Runbook) is written during development. Advanced DevOps level will facilitate Runbook driven Development.
Only Server, Filesystems and Database are being monitored, but no application specific monitoring. DevOps member will take care that application specific monitors are being developed as part of normal delivery process.
A significant amount of money is spent on redundant hardware for failover, but application does not achieve transparent failover. DevOps members understand HA / DR Technologies, will participate in the selection process and ensure that application code will utilize the selected HA / DR Technology.
"Building Resilience into the application code."

DevOps Checklists and Templates

The following Checklists and Templates support DevOps Experts and increase the efficiency of their daily activities:

Operability Requirements Checklist

Operability Requirements are the major group within the group of Non-Functional Requirements, often referred as “Quality Attributes”.
The purpose of those requirements is to ensure that an application / an IT system is easy and efficient to operate with high availability and reliability.
Types of Operability Requirements are e.g.
  • Monitoring Requirements
  • Robustness and Resilience Requirements
  • Fast Troubleshooting
  • Performance
  • Scalability
  • Redundant Hardware / Cluster

Operations Manual / Runbook Template

This template for an IT Operations Manual / Systems-Handbook will help you
  1. that no important item is forgotten and
  2. a common handbook structure is used throughout all systems. This will support easy cross-system troubleshooting and documentation.
The resulting Manual / Runbook is an important deliverable of the overall IT system for
  • compliance with documentation-requirements for systems and processes required by internal QA-department or internal auditing department or external auditors or other organizations and laws
  • There are no doubts that an Application Runbook needs to be delivered.
  • The only question is: When to start writing it?.
DevOps recommends that the operations manual is written during development.
The concept of "Runbook Driven Development" recommends to write it even before writing the test cases and implementation:

More: Arrow right Runbook Driven Development (RBDD)

Within an agile development team that includes an DevOps expert,
  • the architect has the clear vision how the functionalities being developed should work, and how to operate those
  • the developers and testers gain deep understanding during the analysis and specification of backlog items being worked on
  • the tester, participating in analysis and specifications gains the knowledge how to test the backlog item
Conclusion: The team knows all details to be documented in the Operations Manual!
Question: Why to delay writing that chapter of the Operations Manual, resulting later in additional work to explain an document writer what he should write?
Recommendation: Go one step further! - Use the principle of TDD (Test Driven Development) for writing the Operations Manual!

SLA Templates

SLA's can be that tight, that the application needs to be optimized to get a chance to meet those SLA's.
For that reason the SLA's need be known during requirements anlysis!
  • Requirements specification phase (Waterfall) or
  • Sprint Planning Meeting #2 (Agile)

Application Level Monitoring

Experienced DevOps Experts already know that application specific monitoring doesn't come "out of the box" when purchasing a standard monitoring framework.
Those monitoring frameworks do offer modules for
  • server,
  • operating systems and
  • databases
Special application level monitoring modules are being offered for only a very limited number of very popular applications.
For most applications monitoring scripts / API's - which CAN be utilized from monitoring frameworks - need to be implemented within the project.
This free paper provides examples: