DevOps Culture - The Practice of Cloud System Administration - page 181

Simplicity increases the efficiency and speed of communication and avoids confusion.
It also saves time in training, documentation, and support. The goal is to design simple, re-
peatable, reusable solutions.
8.4.4 Continuous Improvement
Each time a process is carried out, the goal is to make it dependably repeatable and more
functional. For example, every time there is a failure, tests are added to the release process
to detect that failure mode and prevent another release with the same failure from being
passed to the next step. Another example might be improving a process that needs occa-
sionalmanualinterventionbyhandlingmoreedgecasesinthetool,untileventuallymanual
intervention is no longer required.
By taking an end-to-end view, we often find opportunities to eliminate processes and
tools,thussimplifyingthesystem.Problemsarefixedbylookingforrootcausesratherthan
making local optimizations that degrade global performance.
The mindset required is eloquently summed up by Kartar ( 2010 ):
Treat your processes like applications and build error handling into them. You can't
predict every ... pitfall ... but you can ensure that if you hit one your process isn't de-
railed.
8.4.5 Common Nontechnical DevOps Practices
DevOpsincludes manynontechnical practices thatfallundertheDevOpsumbrella. Notall
DevOpsorganizationsuseallofthesetechniques.Infact,itisimportanttopickandchoose
amongthem,usingthetechniquesthatareneededratherthanblindlyfollowingalltheprac-
tices for completeness. These are the “people processes”; the more technical practices will
be covered in the next section.
• Early Collaboration and Involvement: Ops staff are included in development
planning meetings, and developers have full access to ops monitoring. Key issues
such as architecting for scalability are jointly developed in the planning stage. (See
Chapter 5 . )
• New Features Review: Ops staff participate in and guide development toward
best practices for operability during design time, not as an after-thought. Key mon-
itoring indicators for services are defined through collaboration. Deployment de-
tails are sketched out so development of deployment code and tests are part of the
main development effort. (See Chapter 2 .)
• Shared Oncall Responsibilities: These responsibilities include not only pager du-
ties shared between developers and Ops staff, but also shared review of oncall
trends—for example, a weekly meeting to review SLA compliance and any out-