Effective Devops Building A Culture of Collaboration Affinity and Tooling at Scale Early Release 1 (Early Release) Edition Jennifer Davis

Effective DevOps Building a Culture of
Collaboration Affinity and Tooling at

Scale Early Release 1 (Early Release)
Edition Jennifer Davis
Visit to download the full and correct content document:
https://textbookfull.com/product/effective-devops-building-a-culture-of-collaboration-af
finity-and-tooling-at-scale-early-release-1-early-release-edition-jennifer-davis/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Building Microservices, 2nd Edition (Early Release, Raw

and Unedited) Sam Newman
https://textbookfull.com/product/building-microservices-2nd-
edition-early-release-raw-and-unedited-sam-newman/
Building Generative AI Services with FastAPI (Early

Release) 1st Edition Ali Parandeh
https://textbookfull.com/product/building-generative-ai-services-
with-fastapi-early-release-1st-edition-ali-parandeh/
Programming Rust, 2nd Edition (Early Release) Jim

Blandy
https://textbookfull.com/product/programming-rust-2nd-edition-
early-release-jim-blandy/
Docker in the Trenches Successful Production Deployment

1 (Early Release) Edition Joe Johnston
https://textbookfull.com/product/docker-in-the-trenches-
successful-production-deployment-1-early-release-edition-joe-
johnston/
Building Machine Learning Systems with a Feature Store:
Batch, Real-Time, and LLM Systems (Early Release) Jim
Dowling
https://textbookfull.com/product/building-machine-learning-
systems-with-a-feature-store-batch-real-time-and-llm-systems-
early-release-jim-dowling/
Architecting HBase Applications A Guidebook for

Successful Development and Design 1 (Early Release)
Edition Jean-Marc Spaggiari
https://textbookfull.com/product/architecting-hbase-applications-
a-guidebook-for-successful-development-and-design-1-early-
release-edition-jean-marc-spaggiari/
SVG Colors Patterns Gradients Painting Vector Graphics

1 (Early Release) Edition Amelia Bellamy-Royds
https://textbookfull.com/product/svg-colors-patterns-gradients-
painting-vector-graphics-1-early-release-edition-amelia-bellamy-
royds/
LLMs and Generative AI for Healthcare (Early Release)

Kerrie Holley
https://textbookfull.com/product/llms-and-generative-ai-for-
healthcare-early-release-kerrie-holley/
Kafka: The Definitive Guide, 2nd Edition (Early

Release) Neha Narkhede
https://textbookfull.com/product/kafka-the-definitive-guide-2nd-
edition-early-release-neha-narkhede/
Effective DevOps
Building a Culture of Collaboration, Affinity, and
Tooling at Scale
Jennifer Davis & Katherine Daniels
Boston
Effective DevOps
by Jennifer Davis and Katherine Daniels
Copyright © 2015 Jennifer Davis and Katherine Daniels. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles ( http://safaribooksonline.com ). For more information, contact our corporate/
institutional sales department: 800-998-9938 or corporate@oreilly.com .
Editor: Brian Anderson Proofreader: FILL IN PROOFREADER

Production Editor: FILL IN PRODUCTION EDI‐ Indexer: FILL IN INDEXER
TOR Interior Designer: David Futato
Copyeditor: FILL IN COPYEDITOR Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest
February 2016: First Edition
Revision History for the First Early Release Edition

2015-05-05: First Release
2015-07-22: Second Release
See http://oreilly.com/catalog/errata.csp?isbn=9781491926307 for release details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Effective DevOps, the cover image, and
related trade dress are trademarks of O’Reilly Media, Inc.
While the publisher and the author(s) have used good faith efforts to ensure that the information and
instructions contained in this work are accurate, the publisher and the author(s) disclaim all responsibil‐
ity for errors or omissions, including without limitation responsibility for damages resulting from the use
of or reliance on this work. Use of the information and instructions contained in this work is at your own
risk. If any code samples or other technology this work contains or describes is subject to open source
licenses or the intellectual property rights of others, it is your responsibility to ensure that your use
thereof complies with such licenses and/or rights.
978-1-491-92630-7
[FILL IN]
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. What is Devops?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
The History of Devops 10
Developer as Operator 10
The Advent of Software Engineering 10
The Age of the Operating System 12
The Beginnings of a Global Community 13
The Age of Applications and the Web 14
Agile Infrastructure 16
The Beginning of DevopsDays 17
Foundational Devops Terminology and Concepts 17
Waterfall 18
Extreme Programming 19
Lean 19
ITIL 20
Agile 20
Community of Practice and Community of Interest 21
Blame Culture 22
Silos 23
Blamelessness 24
Retrospective 25
Organizational Learning 26
Post-Mortem 26
Devops: Adding it All Up 27
Common Devops Misconceptions 28
Devops only involves developers and system administrators. 28
Devops is a team. 28
iii
Devops is a job title. 29
Devops is only relevant to web startups. 30
Devops is about the tools. 30
You need a devops certification. 30
Devops means doing all the work with half the people. 31
There is one “right way” (or “wrong way”) to do devops. 31
It will take X weeks/months to implement devops. 32
Devops is about automation. 32
Devops is a fad. 33
The Current State of Devops 34
The Devops Compact 34
What’s Next in this Book 36
3. Collaboration: Individuals Working Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Introduction 37
Individual Differences and Backgrounds 37
Goals 38
Backgrounds 38
Working Styles 41
Individual Growth 45
The Right Mindset 45
Organizational Pressure 50
Superstars and Superflocks 52
Negotiation Styles 53
From Competition to Collaboration 55
Communication 55
Why Communicate 55
What we Communicate 58
How we Communicate 58
Trust and Empathy 61
Developing Empathy 62
Developing Trust 64
4. Hiring: Choosing Individuals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Introduction and Audience 67
Determining your Hiring Needs 67
Position and Skills 67
Timeframe 68
Budget and Resources 69
Sourcing 70
Diversity 71
Interviewing 76
iv | Table of Contents
Before the Interview 76
During the Interview 77
After the Interview 78
Onboarding 79
Retention 81
Compensation 82
Growth Opportunities 84
Workload 85
Culture and Atmosphere 87
Case Studies 91
Measuring Success 98
Troubleshooting 102
We aren’t getting enough candidates. 102
We aren’t getting diverse candidates. 104
Interviews are a waste of time for the team. 104
People aren’t accepting our offers. 105
Conclusion 105
5. Tools: Selection and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Introduction and Audience 107
Why Tools Matter 109
Why Tools Don’t Matter 112
Tool Ecosystem Overview 115
Configuration Management 115
Version Control 115
Infrastructure Automation 116
System Provisioning 116
Hardware Lifecycle Management 117
Continuous Integration 118
Test and Build Automation 118
Continuous Delivery 120
Application Deployment 120
Continuous Deployment 120
Metrics 120
Logging 121
Monitoring 121
Alerting 122
Events 123
Auditing your Tool Ecosystem 125
Communication 126
Moving Beyond the Basics 136
Optimization: Selection and Elimination of Tools 141
Table of Contents | v
Version Control 142
Infrastructure Automation 146
Artifact Management 149
Work Visualization 149
Metrics 152
Improvements: Planning and Measuring Change 153
vi | Table of Contents
CHAPTER 1
Introduction
<section data-type="sect1"> <aside data-type="sidebar"> <h5>Early Release Edi‐

tion</h5>
<p>This book is a work in progress – new chapters will be added as they are written.
We welcome feedback – if you spot any errors or would like to suggest improve‐
ments, please let us know.</p> </aside>
<h1>Who This Book Is For</h1>
<p>This book is aimed primarily at managers and individual contributors in leader‐
ship roles who see friction within their organizations and are looking for concrete,
actionable steps they can take towards implementing or improving a devops culture
in their work environment. However, individual contributors of all levels who want
practical suggestions for easing some of the pain points they face will find actionable
takeaways.</p>
<p>The audience is made up of a mix of professional roles, as devops is a professio‐
nal and cultural movement that stresses the iterative efforts to break down informa‐
tion silos, monitor relationships and repair when misunderstandings arise between
teams in an organization. Many may be leaders within their organizations who have
worked closely with developers or operations engineers.</p>
<p>The book covers a wide range of devops skills and theory, including an introduc‐
tion to the basic ideas and concepts. It is assumed that you will have heard of the term
devops and perhaps have a rudimentary understanding of devops, tools and pro‐
cesses used in the field.</p>
<p>By the end of Effective Devops, our hope is that you will have a solid understand‐
ing of what having a devops culture means practically for your organization, how to
encourage effective collaboration to help indivdiual contributors from different back‐
7
grounds and teams deal with different goals and working styles to work together pro‐
ductively, how to help teams collaborate to maximize value between them while
increasing employee satisfaction and balancing conflicting organizational goals, and
how to choose tools and workflows for your organization that complement your
organization.</p> </section>
<section data-type="sect1"> <h1>How this Book Is Organized</h1>
<p>This book is broken down into several parts, starting with an introductory chap‐
ter and then covering each of the pillars of devops.</p>
<ul> <li>Chapter I, What is Devops</li> <li>Chapter II, Collaboration: Individuals
Working Together</li> <li>Chapter III, Hiring: Choosing Individuals</li> <li>Chap‐
ter IV, Affinity: From Individuals to Teams</li> <li>Chapter V, Tools: Choosing and
Using Them</li> <li>Chapter VI, Scale: Scaling Everything UP</li> </ul> </section>
<section data-type="sect1"> <h1>Conventions Used in This Book</h1> </section>
<section data-type="sect1"> <h1>Using Code Examples</h1> </section>
<section data-type="sect1"> <h1>How to Contact Us</h1>
<p>We have a web page for this book, where we list errata, examples, and any addi‐
tional information. You can access this page at http://effectivedevops.net.</p>
<p>To comment or ask technical questions about this book, send email to bookques‐
tions@oreilly.com.</p> </section>
<section data-type="sect1"> <h1>Acknowledgements</h1>
<p>Effective Devops would not have been possible without the help and guidance of
many friends, colleagues, and family members.</p> </section> </section>
8 | Chapter 1: Introduction
CHAPTER 2
What is Devops?
What is devops? Some might define it as a software development method, while oth‐
ers might think that it is a set of tools and technologies such as configuration man‐
agement and continuous delivery. We would argue instead that devops is a cultural
movement that seeks to improve both software development and the professional
lives of the people involved in the field. In order to fully understand what we mean
when we’re talking about devops, it is necessary to understand not only what the con‐
cept means and how it is used today, but also the history of how it came to be.
No cultural movement exists in a vacuum. Technology is part of culture. We are born,
accept what is and introduce new cultural aspects as we live. The way that our overall
culture influences technology, and technology influences culture shapes the fabric of
how we live our lives.
Pre-1880, walking was the primary mode of transportation. Cities were compact with
residences and workplaces intermingled. Streets were narrow and inconsistently
paved. As automobiles were introduced, cities made decisions about the organization
and infrastructure either in favor of automobiles or existing pedestrians. These days,
some cities forgo infrastructure planning that factors in pedestrians at all creating
busy roadways with no safe way to travel by foot. Walking shaped the city and how
we worked, and the arrival of new technology changed the landscape accordingly.
Devops is part of the cultural weave that shapes how we work and why. While devops
does involve certain tools and technologies, an equally important part of our culture
is our values, norms, and knowledge. Examining how people work, the technologies
that we use, how technology influeces how we work, and how people influence tech‐
nology can help us make intentional decisions about the landscape of our industry.
This chapter will delve into the evolution of software engineering as it pertains to the
history of devops, define the terms and ideas closest to the movement, and address
9
some common misconceptions that people often have about the subject. Unlike most
histories on the topic, which often start slightly before the first DevOpsDays confer‐
ence in 2009, we will go back further so the reader can gain a richer understanding of
the ideas and principles that have shaped our industry over time, and how that con‐
tinued evolution has changed and grown, making devops not only necessary but
inevitable.
The History of Devops

In this section we will examine the history of the industry and how the recurring pat‐
terns and ideas have shaped the devops movement.
Developer as Operator
In the beginning, the developer was the operator. Early programmers were actually
known as human computers. Jean Bartik, one of the original programmers of the
Electronic Numeric Integrator and Computer (ENIAC) learned how to program the
machine by reviewing hardware and logic diagrams of the device. Programming the
machine and its 18,000 vacuum tubes meant setting dials and changing out cable
connections across 40 control panels. At the time, the focus was on the hardware
engineering and not on the software that Bartik, Kathleen Antonelli, Frances Holber‐
ton, Marlyn Meltzer, Frances Spence, and Ruth Teitelbaum built on the ENIAC.
These women felt the pain to manage the systems as they had to replace fuses and
cables. There were literal bugs in the system.
The Advent of Software Engineering

“Coming up with new ideas was an adventure. Dedication and commitment were a
given. Mutual respect was across the board. Because software was a mystery, a black
box, upper management gave us total freedom and trust. We had to find a way and we
did. Looking back, we were the luckiest people in the world; there was no choice but to
be pioneers; no time to be beginners.
—Margaret Hamilton
In 1961, President John F. Kennedy set the challenge that within the decade that the
United States should land a man on the moon, and return him safely to Earth. With a
deadline and no employees with the necessary skills, the National Aeronautics and
Space Administration (NASA) needed to find someone to write the onboard flight
software needed to accomplish this task. NASA enlisted Margaret Hamilton, a mathe‐
matician at Massachusetts Institute of Technology (MIT) to lead writing this critical
software. In her pursuit of writing this complex software, Hamilton is credited for
coining the term “software engineering”. She also created the concept of priority dis‐
plays, software that would alert astronauts to update configurations in realtime. She
instituted a set of requirement gathering that included:
10 | Chapter 2: What is Devops?

• debugging all individual components
• testing individual components prior to assembly
• integration testing
Space flight was not the only area software was becoming critical. As hardware
became more available, people became more concerned about the impending com‐
plexity of software that did not follow standards across other engineering disciplines.
The growth rate of systems and the emerging dependence on these systems was
alarming. In 1967, discussions were held by the NATO Science Committee compris‐
ing of scientists across countries and industries to do an assessment of software engi‐
neering. A Study Group on Computer Science was formed in the fall of 1967. The
goal was to focus attention on the problems of software. They planned a conference
inviting 50 experts from all areas of industry. The 3 working groups of this confer‐
ence were the Design of Software, Production of Software, and Service of Software.
The goal was an effort to define, describe, and set in motion solving the problems
with software engineering.
At the NATO Software Engineering Conference of 1968, key problems with software
engineering were identified including:
• defining and measuring success

• building complex systems requiring large investment and unknown feasibility
• producing systems on schedule and to specification
• economic pressures on manufacturers to build specific products.
In 1969, the software that Hamilton’s team wrote overrode a manual command that
could have led to the Eagle not landing on the moon. The freedom and trust that the
management gave to the team of engineers working on the onboard flight software
and the mutual respect between team members, led to software that facilitated one of
mankind’s leaps in technology as Neil Armstrong stepped on the moon.
The interactions between management and engineering were studied further by
Diane Vaughan, an American sociologist who did extensive research on the technical
and cultural aspects that led to the space shuttle Challenger disaster in 1986. In Janu‐
ary of that year, the space shuttle orbiter Challenger broke apart 73 seconds into its
flight, killing its 7 crew members. While others did much to evaluate the technical
reasons for the disaster, Vaughan was interested in the human side of things.
When investigating whether or not there was any misconduct during the months
leading up to Challenger’s launch, Vaughan found out that all of the managers
involved had been complying with NASA’s requirements throughout. These require‐
ments included rules about how to make decisions about the technical risks of the
equipment involved with space flight. Vaughan said, “We discovered that they could
The History of Devops | 11

set-up the rules that conformed to the basic engineering principles that allowed them
to accept more and more risk. So they established a social normalization of the devi‐
ance, meaning once they accepted the first technical anomaly, they continued to
accept more and more with each launch. It was not deviant to them. In their view,
they were conforming to engineering and organizational principles. That was the big
discovery. I concluded it was mistake, not misconduct.”
In addition to this idea of the normalization of deviance, Vaughan has done research
on early warning signs that point to issues later on down the road. Early signs are
often considered in the air traffic control industry, where people and organizations
are trained to identify these early warning signs to try and avoid having small mis‐
takes turn into large catastrophes. Looking at the ideas of failure and risk from a
human, sociological point of view in addition to a technical one was something that
would be of great value in many industries going forward.
The Age of the Operating System

In 1979, Usenet was started by university students- Tom Truscott, Jim Ellis, and Steve
Bellovin. It started out as a simple shell script that would automatically call different
computers, search for changes in files on those computers, and copy changes from
one computer to another using UUCP (Unix-to-Unix copy, a suite of programs
allowing for file transfer and remote command execution between computers). To
improve performance it was then rewritten in C. Ellis gave a talk on the “Invitation to
a General Access UNIX network” at an academic Unix users group known as Usenix.
This was one of the first ways to communicate and share knowledge across organiza‐
tions with computers and grew rapidly in use.
While this tool started to facilitate the sharing of knowledge across universities and
corporations, this was also a time where how companies were run was considered
part of the secret sauce. Talking about solving problems outside of the company was
not done, because knowledge of both the problems and the solutions was viewed as
part of the competitive advantage. There was an intentional cultural drive for com‐
petitors to work inefficiently. This stymied a great deal of collaboration and limited
the effectiveness of the communication channels that were available. This cultural
siloization reflected in how companies grew with complexity.
As systems complexity grew, this led to the need for specialization of skills and role
proliferation. This saw the formation of the system administrators specializing in sys‐
tems management and minimizing costs of systems, and the software engineers spe‐
cializing in creation of new products and features to address the new needs. Other
more specialized groups were siloed off as well with the NOC (network operations
center), QA, security, databases, and storage all becoming separate areas of concern.

In 1985, the [National Science Foundation Network](http://www.nsf.gov/about/
history/nsf0050/internet/launch.htm) (NSFNET) was founded to promote advanced
networking in the United States.
This created the institutional Tower of Babel with the different silos all speaking dif‐
ferent languages due to differing concerns. Along with this siloization, the specific
pains of software and the hardware that it ran on was also separated. No longer were
developers exposed to the late night pages of down systems from being on-call, or the
anger expressed by unsatisfied users. Additionally, programming’s trend towards
higher level languages meant that development became more abstracted, moving fur‐
ther and further away from the hardware and the systems engineers of the past.
In an effort to be proactive and prevent service outages, system administrators would
document the set of steps required to do regular operations manually. System admin‐
istrators borrowed the ideas of “root cause analysis” from total quality management
(TQM). This led in part to additional rigor and attitudes towards minimizing risk.
Lack of transparency and change management became the entropy demon that
needed to be defeated.
The Beginnings of a Global Community

As interconnected networks allowed programmers and IT practitioners to begin
sharing their ideas online, people began looking for ways to share their ideas in per‐
son as well. User groups, where practitioners and users of various technologies could
meet to discuss their fields, began to grow in number and popularity. One of the big‐
gest worldwide user groups was DECUS, the Digital Equipment Computer Users’
Society, which was founded in 1961 with members consisting mostly of programmers
who wrote code for or maintained DEC computer equipment.
The US chapter of DECUS ran a variety of technical conferences and local user
groups (LUGs) throughout the United States, while chapters in other countries were
doing the same globally. These conferences and events began to publish the papers
and ideas presented at them in the form of DECUS proceedings, which were made
available to members as a way of sharing information and growing the total knowl‐
edge of the community as well as the interconnectedness of its members. A similar
community specifically for system administrators was found with the Unix Users
Group (founded in 1975 and known today as USENIX) and its special interest group,
the System Administrators Group (known later as SAGE and today as LISA). Sepa‐
rately, NSFNET “Regional-Tech” meetings evolved into the North American Network
Operators’ Group (NANOG), a community specfically for network administrators to
increase collaboration to make the Internet better.
Contrary to the focus on knowledge sharing that was a primary feature of these local
and global user groups, there was at the same time a great deal of secrecy in technol‐
ogy companies regarding their practices. The 1987 film Wall Street exemplified these

ideals, with the character of Gordon Gekko famously saying, “Greed, for lack of a bet‐
ter word, was good”. Companies, in their quests for their own financial and material
successes, kept their processes as closely-guarded secrets.
Companies kept their business practices and technical best practices to themselves,
because if their competitors had inefficient practices, that meant their own relative
success would be more likely. Employees were strongly discouraged or even explicitly
forbidden from sharing knowledge at industry conferences to try and maintain this
sort of competitive advantage. This is in stark contrast to more recent developments,
where communities and conferences are growing around knowledge sharing and
cross-collaboration between companies.
Trade Secrets and Proprietary Information

Information that is not generally known to the public that is suffi‐
ciently secret to confer economic or business advantage is consid‐
ered a trade secret. Information a company possesses, owns or
holds exclusive rights to is considered proprietary. Software, pro‐
cesses, methods, salary structure, organizational structure, cus‐
tomer lists are examples of items that can be considered a
company’s proprietary information. For example, proprietary soft‐
ware is software for which the source code is generally not available
to end users. All trade secrets are proprietary; not all proprietary
information is secret.
In addition to the changes in culture in the industry, commoditiza‐
tion and the costs of knowledge and technology impact what com‐
panies keep secret within their organizations.
The Age of Applications and the Web

In the late 90s, with the ease that new web applications could be created, people at
companies that needed to be able to grow and change quickly to reflect the rapidly
changing market had a problem they needed to overcome.
It was a time of angst and frustration. Endemic in system administration, we had the
culture of “No” and “It’s critical to preserve stability”. In 1992, Simon Travaglia started
posting a series on Usenet called The Bastard Operator From Hell(BOFH) that
described a rogue sysadmin who would take out his frustration and anger on the
users of the system. Toxic operations environments led to individuals viewing the
rogue sysadmin as a hero and emulating behaviors.
In development, we had a culture of “It’s critical to get these changes out” and “I don’t
want to know how to do that because I’ll get stuck doing it”. In some environments
this led to developers risking systems by finding unofficial ways to work around the
processes in place. This led to additional massive cleanups which further solidified

the idea that change is extremely risky. For the singletons in either group that tried to
make change to the overall processes, they’d find themselves stuck in the mire of
becoming the subject matter expert, locked into the positions of support that became
critical to maintain.
In 2001, an invite went out to folks interested and active in the Extreme Program‐
ming (XP) community and others within the field. XP was a form of Agile develop‐
ment that was designed to be more responsive to changing requirements than
previous development software methodologies, known for short release cycles, exten‐
sive testing, and pair programming. Seventeen software engineers got together in
Snowbird Utah to discuss software development. They summarized their shared
common values to capture the adaptiveness and response to change that they wanted
to see in development with an explicit emphasis on human factors. This Agile Mani‐
festo was the rallying cry that started the agile movement.
In 2004, Alistair Cockburn, a software developer who was one of the co-authors of
the Agile Manifesto, described Crystal Clear a software development methodology
for small teams based off of 10 years of research with successful teams. It described 3
common properties frequent delivery of usable code, reflective improvement, and
osmotic communication between developers. Crystal also described 3 priorities
safety, efficiency, and habitability.
This movement continued in software development for several years, and later began
to have its influence felt elsewhere. In 2006, Marcel Wegermann wrote an essay on
how to take the principles of Crystal Clear, Scrum, and Agile and applying them to
the field of system administration. Along with Agile and Scrum, it contained several
ideas that Wegermann argued could be applied to system administration as well as
software development, wanting to bring newer and better practices to the field. In
addition to giving a lightning talk on the subject where he suggested ideas such as
version control for the Linux operating system’s /etc directory, pair system adminis‐
tration, and operational retrospectives, he also started the Agile System Administra‐
tion mailing list.
As web technology continued to grow and evolve, the ways that people communica‐
ted and collaborated online did too. Twitter, an online social networking service was
introduced to the world not even a year later in 2006. At first it seemed very much
like a tool for people wanting to share information in an abbreviated format, for short
attention spans or for celebrities to reach out to fans. In 2007, however, the South by
Southwest Interactive conference saw the use of Twitter skyrocket as Twitter placed
screens in the hallways streaming twitter messages. Twitter quickly became a way for
ad-hoc communities to be formed across the globe. For conferences, it was a way to
get additional value out of the multi-track systems and connect with like minded
individuals. The hallway track, a phrase often used to describe the interactions and
conversations that take place in the hallways of conferences, had expanded from the

physical world to the web where anyone could discover and participate in these ad-
hoc interactions.
Agile Infrastructure
At the Agile 2008 conference in Toronto, Andrew Shafer, a former software developer
who was starting to take a great interest in IT concerns, proposed an Agile Infrastruc‐
ture session. At the same conference, Patrick Debois spoke on incorporating scrum
into operations “Agile Operations and Infrastructure: How Infra-gile are You?”. Pat‐
rick worked with development and operations teams on a project to test data center
migration. One day he would be working on agile development with the developers
and the next day he would be firefighting with the operations team leading to a lot of
context switching; the switching from one process or task to another. Context switch‐
ing for humans cost anywhere from 5 to 30 minutes in lost productivity per context
switch. Observing that he wasn’t the only one interested in Agile system administra‐
tion, Patrick contacted Andrew out of band to discuss agile system administration.
Around the same time, individual companies were beginning to not only make great
strides towards processes that allowed them to keep up with the increasingly rapid
changes of the internet, but were also beginning to share some of their stories pub‐
licly through communities that were building up around popular conferences like the
[O’Reilly Velocity Conference](http://velocityconf.com/).
One such company was Flickr, a popular community site for photographers. After
being purchased by Yahoo in 2005, Flickr needed to move all of the services and data
from Canada to the United States. John Allspaw, a web operations enthusiast who had
worked in systems operations for years, had joined the company as the Flickr Opera‐
tions Engineering Manager to help with its scaling and now was charged with this
massive migration. At the time, Flickr hosted over 3 billion photos with 40000 photos
being served per second. Paul Hammond joined the Flickr Development team in
2007, and became the Flickr Engineering manager in 2008 heading the development
org in collaboration with Allspaw.
Hammond and Allspaw co-presented at Velocity Santa Clara 2009 “10+ Deploys per
Day,” highlighting the revolutionary change that allowed the team to move rapidly.
They didn’t do this by setting out to break down silos or start a big professional and
cultural movement. They were able to collaborate a great deal in their work at Flickr,
which was in contrast to Allspaw’s previous experiences at Friendster, where emo‐
tions and pressures ran high and there was little in the way of inter-team collabora‐
tion. The opportunities to work together that presented themselves were something
that both managers took advantage of. Neither of them woke up one day and decided
that things needed a big change, but rather they recognized the little pieces of work‐
ing together that made things work well. They took note of these little things that
they did together, which ended up becoming much bigger cultural changes.

The Beginning of DevopsDays
“Don’t just say no, you aren’t respecting other people’s problems… #velocityconf
#devops #workingtogether”
—Andrew Clay Shafer (@littleidea)
This tweet, from Andrew Shafer on June 23 2009, caused Patrick Debois to lament
that even though he was watching remotely, he was unable to attend that year’s Veloc‐
ity conference in person. Paul Nasrat, at the time a lead systems integrator at the
Guardian, tweeted in reply, “Why not organize your own Velocity event in Belgium”.
Inspired Patrick did just that, creating a local conference that would allow for devel‐
opers, system administrators, toolsmiths and others in those fields to come together.
In October of that year, the first DevopsDays conference took place in Ghent. Two
weeks later, he wrote:
“I’ll be honest, for the past few years, when I went to some of the Agile conferences, it
felt like preaching in the desert. I was kinda giving up, maybe the idea was too crazy:
developers and ops working together. But now, oh boy, the fire is really spreading.”
—Patrick Debois
That first DevopsDays event ignited the powder keg of unmet needs, people separated
in silos frustrated with the status quo identified with devops and a way of describing
the work they felt they were already doing. The conferences grew and spread as indi‐
viduals started up new DevOpsDays across the world. With the availability of the
real-time communication platform of twitter, the hallway track never ended and
#devops took on a life of its own.
As we reflect on history, we see the trend of a focus on the outcome. Many have seen
the “10+ deploys a day” presentation from John Allspaw and Paul Hammond and
taken away from it that the importance was the 10+ deploys per day, the quantity of
deployments in a day. The title “10+ deploys a day” was the hook which pulled people
in to see the presentation. The content of the talk how they achieved something that
seemed impossible and not a simple metric. You can’t declare “doing devops success‐
fully” simply because you are “doing 10 deploys a day”. This fixation on an outcome
increases the stress to the human who is already stressed out because workflow of the
organization doesn’t allow for the adventurous dedication and commitment enabled
with freedom and trust to be happy and productive humans building new leaps for
mankind. As we will show in later chapters, focusing on the processes is a better way
of thinking, because devops is about how we do things, and why, not just what we end
up doing with those things.
Foundational Devops Terminology and Concepts

In order to effectively discuss the tools and techniques required to implement devops,
it is necessary to define some of the major terms and concepts surrounding it. When
Foundational Devops Terminology and Concepts | 17

we take a look at the history of both software development and operations, we notice
several broad concepts there that should be examined in order to understand the evo‐
lution of devops. Some of these terms are not foundational concepts of devops itself,
but anti-patterns that devops tried to overcome. This section will discuss those con‐
cepts as well as ideas related to devops as it exists today and end with a definition of
devops itself.
Waterfall
The waterfall methodology or model is a software development process with an
emphasis on a sequential progression from one stage of the process to the next adap‐
ted from hardware engineering. One of the driving forces behind this model was the
idea that bugs were easier to fix the earlier in the development process they were dis‐
covered, and so sought to ensure that each stage of the process would be completely
finished before any work was started in the next. The original stages were require‐
ments specification, design, implementation, integration, testing, installation, and
maintenance, and progress was visualized as flowing from one stage to another.
Figure 2-1. A Visual Representation of the Waterfall Model
Software development under the waterfall model tended to be very highly structured,
with a large amount of time being spent in the requirements and design phases, with
the idea that if both of those were completed correctly to begin with it would cut

down on the number of mistakes that would be found later. Part of the appeal of this
stemmed from the high costs of delivering and changing software that was dis‐
tributed on CD-ROMs or floppy disks to be installed by hand. Since fixing a bug on
such software would require, for example, manufacturing and distributing another
CD-ROM with a software patch, it was much more cost-effective to spend the time to
get the design and specifications right up front.
The waterfall method makes sense in these cases where the cost of delivering software
is high or for projects with requirements unlikely to change. As with every methodol‐
ogy, the waterfall method has its pros and cons.
Some advantages of using the waterfall method is its emphasis on documentation,
discrete understandable phases and milestones. Documentation alleviates knowledge
lost when individuals leave or new employees join a project. With understandable
discrete phases, project members can finish a phase of the project and pass on to
other members at the significant milestones.
Project manager Mary Lotz has argued that gathering and specifying all requirements
in advance of any work being done is often the most difficult part of any software
development project. Customers often don’t know their exact requirements, at least
not enough to make sure that they are 100% completely specified, and requirements
will often change over time. As software is developed, limitations may be discovered
that cause requirements or deadlines to change.
Projects that require more flexibility might benefit from examining some more itera‐
tive or agile methodologies as well. As we will examine further in later chapters, a key
part of devops is being able to assess and evaluate different tools and processes to find
the most effective one for your environment, but it isn’t so rigidly defined as to pro‐
hibit any methodologies, even older ones such as waterfall.
Extreme Programming
• Communication
• Feedback
• Simplicity
• Courage
• Respect
Lean
The idea of lean originally stemmed from lean manufacturing, which was a system
for eliminating waste within a manufacturing process. The Toyota Production System
of the 1990s, also called “Just In Time” production is perhaps the best-known exam‐

ple of lean manufacturing, with the main goals of the process being to eliminate waste
and design out inconsistency. Lean systems focus on the parts of the system that add
value by eliminating waste everywhere else, whether that be over-production of some
parts, defective products that have to be re-built, or time spent waiting on some other
part of the system. Stemming from this are the concepts of lean IT and lean software
development, which apply these same concepts to software engineering and IT opera‐
tions. Waste to be eliminated in these areas can include unnecessary software fea‐
tures, communication delays, slow application response times, or overbearing
bureaucratic processes.
ITIL
ITIL, formerly known as Information Technology Infrastructure Library, is a set of
practices defined for managing IT services. It is published as a series of five volumes
which describe its processes, procedures, tasks, and checklists, and is used to demon‐
strate compliance as well as measure improvement towards that end. ITIL grew out of
a trend that saw the growing number of IT organizations in the 1980s using an
increasingly diverse set of practices. The British Central Computer and Telecommu‐
nications Agency developed a set of recommendations as a way to try to standardize
these practices. First published in 1989, the books and practices have grown over the
years, with the five core sections in the most recent (2011) version being service strat‐
egy, service design, service transition, service operation, and continual service
improvement.
IT analyst and consultant Stephen Mann notes that while there are many benefits that
come with ITIL’s standardization and while there are over 1.5 million ITIL certified
people worldwide, it has some areas where practitioners again might want to put
additional focus. Mann noted that ITIL is often more on the side of being reactive
rather than proactive, so we suggest organizations who have been using ITIL take
note of ways that they can try to add more proactive planning and customer focus to
their practices, as we will cover in later chapters.
Agile
Started with the writing of the Agile Manifesto in 2001, agile is the name given to a
group of software development methodologies that are designed to be more light‐
weight and flexible than previous methods such as waterfall. The developers that cre‐
ated the Manifesto wrote:
We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation

Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left
more.
—The Agile Manifesto
Agile methodologies included processes such as Scrum, Extreme Programming, and
Feature-Driven Development. While this section is not intended to be a complete les‐
son on the history of software development, it is important to note that these new
methods placed a heavy emphasis on collaboration, flexibility, and the end result of
working software, ideas which are closely related to the core tenets of devops. In their
2011 paper, “Overview and Guidance on Agile Development in Large Organization,”
authors Barlow et al noted that many large organizations find agile practices to be too
flexible or extreme, but the ideas behind them are continuing to evolve along with the
field of software development.
Is Devops Just Agile?

Devops shares many common characteristics with the Agile movement, especially
with the focus on individuals, interactions, and collaboration. You might wonder if
devops is just “rebranded” Agile. While devops has certainly grown around Agile
principles, it is a separate cultural movement steeped in history of software engineer‐
ing with a broader reach that is inclusive of more than just developers. Devops
extends Agile ideas and applies them to an entire organization, not only the develop‐
ment process. As we will see in detail in later chapters, devops has cultural implica‐
tions far beyond what was seen with Agile and a focus that is broader than speed of
delivery.
Community of Practice and Community of Interest

Communities of practice are groups of people who share the same role or concern
and meet regularly to improve how they perform in an organization. Every role
within an organization has the opportunity to form a community of practice, so there
could be one community for developers, one for QA and testing engineers, and
another for scrum masters. Communities of practice could also form around specific
tools or languages, but in either case they are not restricted to people from any one
project or team. These communities tend to work best when they are not mandated
by management, but rather allowed to grow and change organically. Community
activity may ebb and flow over time as roles and projects do. It is important to note
that communities of practice are restricted to those people who are actively partici‐
pating in the role that the community is focused on so that learning and discussion
will come from peoples’ real-world knowledge and experience.

A community of interest is similar to a community of practice, but instead of being
limited to practitioners only, tends to be made up of people who are interested in the
management, governance, and communication of the teams involved in an organiza‐
tion. They might take responsibility for overseeing or creating communities of prac‐
tice, or discuss other higher-level issues that don’t have as much effect on the day-to-
day, real-world issues that practitioners are discussing. Some communities use the
term in a different way, meaning a community of interest to be anyone who is interes‐
ted in discussing a particular topic, team, or technology even if they don’t practice it
themselves. Both communities of practice and communities of interest are intended
to be cross-functional, with emphasis being placed on learning and common goals.
It should be noted that while these communities of practice and interest are often
seen in Agile organizations, they are not restricted to it. As an example, Linux user
groups are communities of practice, often local, where active practitioners or users of
Linux operating systems will discuss topics relevant to their work, such as dealing
with Linux security issues or how to improve the performance of databases running
on Linux systems. A community of interest might take the form of a Meetup group -
a Python community of interest would probably include both professional Python
programmers and people interested in playing around with or learning the language.
Blame Culture
A blame culture, or blameful culture, is one that tends toward blaming and punishing
people when mistakes are made, either at an individual or organizational level. In this
kind of culture, a root cause analysis as part of a post-mortem or retrospective is gen‐
erally misapplied with the search for one thing that ultimately caused a failure or inci‐
dent. If this analysis happens to point towards a person’s actions as being the “root
cause”, that person will be blamed, reprimanded or even fired for their role in the
incident. This sort of culture often arises from one that must answer to external audi‐
tors, or where there is some top-down mandate to improve performance according to
some set of metrics.
Heavily siloed environments that lack an appreciation for transparency are fertile
ground for blame culture. If management is set on finding one person or group of
people to blame for each incident that occurs, in order to get rid of that “bad apple”,
individual contributors will be motivated to try to shift blame away from themselves
and their own teams onto somebody else. While this sort of self-preservation is
understandable in such an environment, it doesn’t lend itself well to a culture of
openness and collaboration. More than likely, people will begin withholding informa‐
tion about incidents, especially with regards to their own actions, in an effort to keep
themselves from being blamed. Outside of incident response, a culture of blame that
calls people out as a way of trying to improve performance (such as which developers
introduced the most bugs into the codebase, or which IT technician closed the fewest
tickets) will contribute to an atmosphere of hostility between coworkers as everyone

tries to avoid being called out. When people are too focused on simply avoiding hav‐
ing a finger pointed at them, they can’t be focused as much on learning.
Silos
A departmental or organizational silo is a term describing the mentality of teams that
do not share their knowledge with other teams in the same company. Instead of hav‐
ing common goals or responsibilities, siloed teams have very distinct and segregated
roles. Combined with a blameful culture this can lead to information hoarding as a
form of job security (“If I’m the only one who knows how to do X, they won’t be able
to get rid of me”), difficulty or slowness completing work that involves multiple
teams, and decreases in morale as teams or silos start to see each other as adversaries.
Often in a siloed environment you will find different teams using completely different
tools or processes to complete similar tasks, people having to go several levels up the
managerial chain of command in order to get resources or information from people
on another team, and a fair amount of “passing the buck”, moving blame or responsi‐
bility to another team.
The issues that can come from organizational silos take time, effort, and cultural
change to break down and fix. Having software developers and system administrators
or operations engineers be siloed, and trying to fix the issues in the software develop‐
ment process that came from that, was a big part of the root of the devops movement,
but it’s important to note that those are not the only silos that can be present in an
organization. Cross-functional teams, discussed later, are often touted as being the
anti-silos, but these are not the only two options, and in fact just because a team com‐
prises only one function does not necessarily make it a silo. Silos come from a lack of
communication and collaboration between teams, not just from a separation of
duties.
The Old View and the New View

In his 2006 book, “The Field Guide to Understanding Human Error,” professor of
human factors Sidney Dekker laid out two ways that organizations usually approach
issues. His “old view” describes a mindset in which human error is seen as something
that causes systems to fail and needs to be eliminated, the idea being that mistakes are
only made by “bad apples” who need to be rooted out and dealt with. This view is
very often found in blameful cultures as it assumes that errors are caused by malice or
incompetence and the individuals responsible must be blamed and shamed (or sim‐
ply fired). In contrast to this is his “new view” which says that human errors are
structural rather than personal - rather than making mistakes due to incompetence,
people make the choices and take the actions that make the most sense to them at the
time based on the circumstances they find themselves in, and that people should be
educated and complex systems considered holistically when looking to minimize or
respond to issues.

Root Cause Analysis
Root Cause Analysis(RCA) is a method to identify contributing and root causes of
events or near-miss/close calls and the actions adequate to prevent recurrence. It’s an
iterative process that is continued until all organizational factors have been identified
or until data is exhausted.
Organizational factors are any entity that exerts control over the system at any stage
in its life cycle including but not limited to design, development, testing, mainte‐
nance, operation, and retirement.
One method of identifying root causes is the 5-Whys. This method employs asking
“why” until the root causes are identified. It requires that the individuals answering
“why” have sufficient data to answer the question appropriately.
A second and more systematic approach is to create a Ishikawa Diagram. Developed
by Kaoru Ishikawa in 1968, this causal diagram gives a way to visualize and group
causes into major categories to identify sources of variation, relationships among
sources, and provide insight into process behaviors.
Often RCA is associated with determining a single root cause. Tools that provide
event management often only allow a single assignment of responsibility. This limits
the usefulness of root cause analysis as it focuses attention on the direct causes rather
than the additional elements that may be contributing factors.
Human Error
Human error is a term often used as the root cause in a root cause analysis, being the
idea that a human being made a mistake that directly caused a failure. With this often
comes the implication that a different person would not have made such a mistake,
which is commonly seen in a blame culture when somebody has to be reprimanded
for their role in an incident. Again, this is an overly simplistic view, and is used pre‐
maturely as the stopping point for an investigation. It tends to assume that human
mistakes are made due to simple negligence, fatigue, or incompetence, neglecting to
investigate the myriad factors that contributed to the person making the decision or
taking the action they did. In a blameful culture, discussion stops with the finding
that a specific person made a mistake, with the focus often being on who made the
mistake and the end result that it caused. In a blameless culture or a learning organi‐
zation, a human error is seen as a jumping off point rather than an ending one, start‐
ing a discussion on the context surrounding the decision and why it made sense at
the time.
Blamelessness
Blamelessness is a concept that arose in contrast to the idea of blame cultures dis‐
cussed previously. Though it had been discussed for years previously by Sidney Dek‐

ker and others, this idea was really brought to prominence with John Allspaw’s post
on blameless post-mortems, with the idea that incident retrospectives would be more
effective if they focused on learning rather than punishment. A culture of blameless‐
ness exists not as a way of letting people off the hook, but to ensure that people feel
comfortable coming forward with details of an incident, even if their actions directly
contributed to a negative outcome, because it is only with all the details of how some‐
thing happened can learning begin to occur. We have to remember that the point of a
post-mortem or retrospective after an incident is to prevent the same thing from hap‐
pening in the future, and only if you accept the bad apples theory of Dekker’s “old
view” does it make sense to focus on the identification, blame, and removal of those
bad apples. In the New View, with a focus on identifying many contributing factors
and learning from each of them, blamelessness helps foster an environment where
those factors can be brought to light.
Organizations used to the idea of blaming and punishing people for making mistakes,
up to and often including firing them, might wonder if there is an exception to
blamelessness for repeated mistakes. They might ask, if someone makes the same
mistakes over and over again, doesn’t that indicate an inability or an unwillingness to
learn? The “new view” doesn’t work this way. In the new view, we are supposed to
examine all the circumstances surrounding an incident and how they contributed to
the actions of the people involved so that the system as a whole (including the human
operators) can be improved. If people keep making the same mistakes, how thorough
or effective were the debriefings that followed these incidents? Was anything changed
to improve the safety of the system as a whole? The philosophy of blamelessness still
applies - people should not be blamed for mistakes that stemmed from systemic or
organizational failures, especially if the organization could not or would not make
changes that would help protect against those failures.
Retrospective
A retrospective is a discussion of a project that takes place after it has been comple‐
ted, where topics such as what went well and what could be improved in future
projects are considered. Retrospectives usually take place on a regular (if not neces‐
sarily frequent) basis, either after fixed periods of time have elapsed (every quarter,
for example) or at the end of projects. A big goal is local learning - how can the suc‐
cesses and failures of this project be applied to similar projects in the future. Retro‐
spective styles may vary, but usually include topics of discussion such as:
• What Happened? What was the scope of the project and what ended up being
completed.
• What Went Well? Ways in which the project succeeded, features that the team is
especially proud of, what should be used in future projects.

• What Went Poorly? Things that went wrong, bugs that were encountered, dead‐
lines that were missed, things to be avoided in future projects.
Organizational Learning
A learning organization is one that learns continuously and transforms itself . . . .
Learning is a continuous, strategically used process — integrated with and running
parallel to work.
—Karen E. Watkins and Victoria J.
Marsick, Partners for Learning
Organizational learning is the process of collecting, growing, and sharing the body of
knowledge that an organization has. A learning organization is one that has made
their learning more deliberate, setting it as a specific goal and taking actionable steps
to increase their collective learning over time. Organizational learning as a goal is
part of what separates blameful cultures from blameless ones, as blameful cultures are
often much more focused on punishment than on learning, whereas a blameless or
learning organization takes value from the experiences it has and looks for lessons
learned and knowledge to be taken away, even from negative experiences. Learning
can happen at many different levels, including individual and group as well as organi‐
zation, but organizational learning has higher impact to companies as a whole, and
companies who practice organizational learning are often more competitive than
those who don’t.
Post-Mortem
Unlike the planned, regular nature of a retrospective, a post-mortem occurs after an
incident or outage, for cases where the outcome of an event was surprising to those
involved and at least one failure of the system or organization was revealed. Whereas
retrospectives occur at the end of projects and are planned in advance, post-mortems
are unexpected before the event they are discussing. Here the goal is organizational
learning and they benefit from having a systemic and consistent approach that often
include topics such as:
• What Happened? A timeline of the incident from start to finish, often including
communication or system error logs.
• Debrief Every person involved in the incident gives their perspective on the inci‐
dent, including their thinking during the events.
• Remediation Items Things that should be changed to increase system safety and
avoid repeats of this type of incident.
In the devops community, there is a big emphasis placed on having post-mortems

and retrospectives be blameless. While it is certainly possible to have a blameful post-

mortem that looks for the person or people “responsible” for an incident in order to
call them out, that runs counter to the focus on learning that is present in the devops
movement.
Devops: Adding it All Up

The danger for a movement that regards itself as new is that it may try to embrace
everything that is not old.
—Naturalistic Decision Making
After defining all of these related terms, it is tempting to try to tie them all together
into one simple definition of devops. However, if it were that easy, there wouldn’t
have been nearly as much debate over the past five years as to what devops is and
isn’t. This book is not a prescription for the One True Way of doing devops. We don’t
offer you devops in a box, devops-as-a-service, or tell you that you are Doing Devops
Wrong. What this book offers is a collection of ideas and approaches for improving
individual collaboration, team and organizational affinity, and tool usage throughout
a company or organization, and discuss how these concepts operate at different sizes
and scales. Every organization is unique, and so while there is no one-size-fits-all way
of doing devops, these common themes can be applied in different ways to every
organization that wants to improve both the quality of their products and the effi‐
ciency and well-being of their employees.
While the term devops itself is a portmanteau of “development” and “operations”, the
core concepts of the devops movement apply much more broadly than just the devel‐
opment and operations teams. Companies building products or services are much
more complex than simply those who write the software and those who maintain it in
production. Like any complex system with many interdependencies it must be treated
differently than the comparatively simple single “system engineer” that the industry
began with. To be successful, a business needs to have many other teams and skills
involved, including QA, security, network and database specialists, and even support,
sales, and marketing, and all of those must work well together to be competitive in
today’s fast-paced environment.
Sometimes, in order to get around the issue of defining devops and get people talking
about concepts and principles, they will use an exaggerated example of so-called
“bad” behaviors as a way of focusing on the “good” behaviors that they see as being
“devops”. In order to talk about effective inter-team collaboration, someone might use
a cartoonish example of a company that creates a devops team that serves only to act
as go-betweens for the development and operations teams. It’s an extreme example
(though there are almost certainly places where it’s actually happened) but it serves to
get people talking about something more meaningful and applicable than a defini‐
tion.
Devops: Adding it All Up | 27

In the field of cognitive science, a folk model is a word or phrase that is used as an
abstraction for more concrete ideas, and often substituted for those things, with the
folk model being easier to understand than the concept really being discussed. An
example of this is the term “situational awareness” which is often used as a stand-in
for more specific ideas like perception and short-term memory. Folk models are not
necessarily bad, but they can be problematic when different groups of people use the
same term to refer to different underlying concepts. We would argue that in many
ways, devops has become a folk model. Different people use it to mean many differ‐
ent things, which can cause miscommunication to occur - people will often spend
more time arguing over what “devops” means, what folk model they are using for it,
than they spend focusing on the ideas that they really want to discuss. For this reason,
providing one definition of “devops” can be distracting away from what we want to
talk about instead.
At the end of this chapter we will discuss our five pillars of devops as well as what the
rest of this book will cover, and it is those core concepts that are what this book is
designed to talk about, not the particular definition or folk model we will be using.
Common Devops Misconceptions

To clarify even more what we mean when we discuss devops in this book, we will
clear up what are some common misconceptions about what devops is.
Devops only involves developers and system administrators.

While the name might indicate that it involves only developers and operations, and
though the DevopsDays conference tagline is “the conference that brings develop‐
ment and operations together”, the concepts and ideas of devops can and should be
expanded to include others as necessary. There is no one definitive list of which
teams or individuals should be involved or how, just as there is no one-size-fits-all
way to “do devops”.
Ideas that help development and operations teams communicate better and work
more efficiently together can be applied throughout a company. Any software devel‐
opment organization should be considering aspects of the product life cycle including
security, QA, and support in order to be most effective. In later chapters we will dis‐
cuss considerations for involving these other teams into an effective devops environ‐
ment.
Devops is a team.
Some people will argue very strongly against the creation of a designated “devops
team”. There are several valid reasons for this argument. Simply creating a team called
devops, or renaming an existing team to devops as a way to check off an item on a

Another random document with
no related content on Scribd:
There they found Laddie wide awake, sitting in the assembly room
of the station house, while several officers, who were on reserve
duty, were laughing and joking with him.
“He’s far from being asleep,” said Mr. North.
“I should say so!” agreed Mr. Bunker. “Laddie boy, what in the
world are you doing down here?” he asked the little fellow.
“I came down to find out about a riddle,” he answered.
“And he’s had us all guessing riddles ever since he walked in here
about an hour ago,” chuckled the police sergeant in charge of the
station. “He’s a great boy!”
“I didn’t perzactly come down here to ask riddles,” said Laddie.
“But I wanted to make up a riddle about a policeman to ask Farmer
Joel when I got to the farm, and I had to see a police station inside to
make up the riddle.”
“Well, did you make the riddle up?” asked the sergeant, with
another laugh. Life at the station was very often dull, and the men on
duty welcomed any little change.
“Yes, I got a riddle,” Laddie announced. “’Tisn’t very good, but
maybe I can think of a better one after a while. This is it. Why is a
police station like a candy shop?”
“Ha! Ha!” laughed the sergeant. “That may be a riddle, but I can’t
see it. Nothing could be more different than a candy store and this
police station.”
“Yes, there’s something alike in each of them,” went on Laddie.
“Do you all give up?” he asked. “Can you tell why a police station is
like a candy shop?”
“Is it because when people are brought here they have to stick?”
asked Adam.
“Ha! Ha! That’s pretty good!” laughed the sergeant. “I’d never think
of that myself! Pretty good! A police station is like a candy shop
because people have to stick here! And it’s true! They do have to
stick if we arrest them and put them in a cell. And if there’s sticky
candy on the floor of a candy shop they’d stick there. Pretty good!”
“No, that isn’t the reason,” said Laddie. “Listen. I’ll tell you. A police
station is like a candy shop because it’s full of sticks. Sticks, you
know—the policemen’s clubs. They’re like sticks of candy, you
know!”
“Ha! Ha!” laughed the sergeant again. “That’s pretty good! I must
remember that to tell the captain. Well, good night to you,” he added,
as Mr. Bunker led Laddie out, thanking the sergeant and his men for
having entertained and kept the little boy.
On the way home in the automobile Mr. Bunker said Laddie should
not have slipped off and gone down the street to the police station
without telling some one about it.
“We were all worried, Laddie,” went on his father.
“I’m sorry,” the little fellow said. “I won’t do it again. But I got to
thinking I could make up a good riddle about a policeman, and I
thought it would be better if I could see one before I made the riddle,
so I just went.”
“Well, it’s a pretty good riddle—I’ll say that,” chuckled Adam North.
“Maybe you can make up some about the farm when you get there.
Farmer Joel likes jokes and riddles.”
“I’ll make up a lot of them for him,” kindly offered Laddie, as if he
had a stock of riddles constantly on hand and could turn them out at
a moment’s notice.
“Oh, Laddie, you bad boy, where have you been?” asked his
mother when he reached home.
When they told her his riddle about the police station and candy
shop, she could not help laughing.
A few days after this everything was ready for the start to Farmer
Joel’s. Mr. Bunker had arranged to leave his real estate business in
charge of his men at the office, and Mrs. Bunker prepared to close
the house, taking Norah with her to cook at the farm.
The children’s clothing had been packed in valises and trunks, and
piled in the big auto truck which was filled with straw to make a
comfortable resting place for the six little Bunkers on their forty-mile
trip.
As I have told you, the children and their father would ride in the
big truck with Adam, and Mrs. Bunker would follow with Norah in the
touring car, the children’s mother doing the driving.
All was one grand excitement in the home of the six little Bunkers
when the morning came on which they were to leave for the farm.
Every one seemed to be talking at once, and certainly the children,
Violet especially, never seemed to have asked so many questions
before.
Laddie, too, was on the alert. He was working on a new riddle. He
spoke of it to Russ.
“It’s about a tree,” said Laddie.
“Oh, I know that old riddle,” Russ said. “You mean why is a tree
like a dog? Because it has a bark.”
“No, it isn’t that one,” Laddie said eagerly. “This is a new riddle.
Now I have it! What’s the difference between a tree and a bird? Can
you answer that?”
“Let me see now,” murmured Russ, who wanted to please his little
brother. “The difference between a bird and a tree. Well, one flies
and the other doesn’t.”
“Nope!” cried Laddie. “I’ll tell you. A tree leaves in the spring and a
bird leaves in the fall. See what I mean? A tree leaves in the spring
—the leaves come out. But a bird leaves in the fall. The bird leaves
the North and flies down South where it’s warm.”
“I don’t think that’s a very good riddle,” said Russ.
“Well, maybe I can think of a better one after a while,” Laddie
remarked cheerfully. He certainly was good-natured.
Now that the time of going to the farm had arrived, Violet was
eager to find out all about the animals. She fairly pestered Adam with
wanting to know things. She asked:
“How many chickens are there? How many cows? Did you ever
count the bees?”
“Count the bees? Good land, no!” laughed Adam. “There’s millions
of ’em and they never keep still long enough to be counted. Besides,
if I tried they might sting me.”
“Well,” said Vi, “are there any——”
“Violet, get in the truck and sit still,” ordered her mother firmly, and
Violet obeyed.
Everything was ready for the start. Mr. Bunker was counting the
children and the trunks and the satchels, to make sure none was
missing, when Rose asked:
“Where’s Margy?”
“Here she comes,” said Russ, as he noticed his little sister
appearing around the corner of the house.
“What in the world is she carrying?” asked Mr. Bunker.
And well might he inquire. For Margy was half dragging half
carrying a large pasteboard box which seemed alive, for it swayed
from side to side and seemed about to leap away.
“Margy, what have you there?” called her father.
Before she could answer the box gave a sudden lurch to one side,
Margy lost her balance, and down she went on the path in a heap,
the box tumbling over and over as if it had suddenly come to life.
What could it be?
CHAPTER VI
SOMETHING IN THE STRAW
Five little Bunkers, with their father, their mother, Norah, and Adam
North looked at one little Bunker in a queer plight. That one little
Bunker was Margy.
After her fall Margy rolled along the path a short distance, for she
was a round little girl, quite chubby and, as her father often said,
“about as broad as she was long.”
As Margy rolled along, the box she had been carrying also rolled.
There was nothing very strange in Margy’s rolling over and over
after a tumble. She often did that. So did the other little Bunkers. So,
also, do you if you are little and fat.
There was also nothing very strange in the box, which Margy had
been carrying, rolling over. That is, there would not have been
anything strange if the box had just rolled in one direction.
But it did not. It rolled this way and that way and the other way and
then it rolled this way again, in such a strange manner that Russ
cried:
“What in the world can be in that box to make it go that way?”
“It’s just as if it was alive!” said Rose.
“Maybe it’s a riddle!” suggested Laddie.
Mrs. Bunker had gone to Margy to pick her up. Beyond a scratch
or two and some bruises, together with some dust on her dress,
Margy was unharmed. She was used to cuts and bruises, so these
did not much matter. Nor did the dust.
Russ ran to pick up the queer, rolling box, calling out:
“What’s in it, Margy?”
Before she could answer there came from within the box, the
cover of which was fitted tightly on, a little yipping whine and bark.
“Oh, it’s a dog!” cried Mun Bun. “I want to see the dog!”
“Dog!” exclaimed Violet. “It must be a terribly little dog to be in a
box like that.”
“Margy, what have you in the box?” asked her father, as Russ was
trying to take off the cover.
“It’s a—now—a puppy!” answered Margy.
“A puppy!” cried the other five little Bunkers, while Margy’s mother
asked:
“Where did you get the puppy, Margy?”
“I went over to Tommy Baker’s house. His dog has some little
puppies, and I took one and put it in this box ’cause I want to take a
puppy with me to the farm,” Margy answered.
The others laughed.
By this time Russ had managed to get the cover off the box, and a
cute little puppy stuck his head out, and, with his tongue, began
licking Russ’s hands. I suppose that was the puppy’s way of telling
how glad he was to get out of the box.
“Oh, isn’t he sweet!” cried Rose.
“Could we keep him?” begged Violet.
“I love him an’ he’s my puppy!” announced Margy.
“Well, the next time you love a puppy don’t shut him up in a box
without any air, and don’t drop him so the box rolls and he turns
somersaults,” advised Daddy Bunker. “Russ, you run back to Mr.
Baker’s with the little dog, and tell him Margy didn’t really mean to
take it.”
“Oh, Daddy! can’t I keep it?” begged Margy.
“No, dear. It belongs to Tommy Baker. You’ll find animals enough
out at Farmer Joel’s, anyway,” said her mother, as Russ started back
with the puppy in his arms.
For a moment it seemed as if Margy would cry, but Mun Bun kept
her tears back by saying:
“It was awful funny when he did roll over and over in the box. I like
a puppy to do that!” And when the others laughed at Mun Bun’s
funny way of saying this, Margy also laughed.
Russ came running back, having left the puppy with the others, a
last look was taken around the house to see that all was in good
order, and then Mrs. Bunker and Norah started off in the touring car
and Daddy and Adam North started in the big straw-filled truck with
the six little Bunkers.
“Oh, this is great! It’s going to be lots of fun!” exclaimed Russ, as
they rumbled along.
“I hope there’s a big, old-fashioned kitchen at Farmer Joel’s,” said
Rose. “Mother said I might help her with the baking of cake and
pies.”
“Well, I’ll help with the eating,” laughed Russ. “I hope there’s a
brook on the farm. I want to make a water wheel and build a little toy
mill that the water wheel will turn.”
“I’ll help you,” offered Laddie, as Russ whistled merrily.
The way to Cedarhurst where Farmer Joel lived was along a
pleasant road, and the children, sitting on the straw in the big truck,
enjoyed looking out through openings in the canvas sides.
“Did we bring anything to eat?” asked Vi, after a few miles had
been journeyed.
“No, daddy said we were going to stop in Westfield for our lunch,”
explained Rose. “We are going to meet mother there and all eat
together in a restaurant.”
“Oh, that’ll be fun!” declared Vi.
“It would be more fun if we could camp beside the road, make a
fire and cook something,” suggested Russ.
“If I had a gun I could shoot something and we could cook that,”
cried Laddie.
“Pooh! What could you shoot? A bear?” asked his twin sister.
“No,” he drawled. “But maybe I could shoot a chicken.”
“If you did the farmer that owned it would have you arrested,”
declared Russ. “I guess it will be better for us to eat in the
restaurant.”
Adam North, who sat up in the front seat with Daddy Bunker,
suddenly turned the truck off to one side of the road and brought the
big machine to a stop.
“Oh, are we there already?” cried Rose, leaping up from the straw
where she had been sitting beside Russ.
“Are we at Farmer Joel’s?” asked Violet eagerly.
“I want to wide on a horsie!” demanded Mun Bun.
“No, we aren’t there yet,” answered Adam. “But I need some water
in the radiator of the auto, so I’ll just stop here and get some. There’s
a farmer here whom I know.”
“May we get out?” asked Russ, for he thought perhaps they might
not stop long enough for this.
“Oh, yes, get out and stretch your legs,” his father told him.
“I’ll wait here five or ten minutes and cool down the engine,” added
Adam.
With whoops and shouts of delight the six little Bunkers piled out
of the truck and ran up and down the road. The machine had come
to a stop with the open rear end close to a wooden platform, which
was just as high as the floor of the big car. From the platform a flight
of steps led to the ground, and the Bunker children got out on this
platform and so descended.
“What’s this for?” asked Violet, with her usual way of starting
questions.
“This,” her father told her, “is a milk platform.”
“What’s a milk——” began Vi, but her father held up his hand.
“I’ll tell you all about it, and then you won’t have to ask any more
questions,” he said, with a smile. “This platform is built for the farmer
to set his cans of milk on. It is made high, so it is easy to roll the
cans of milk from the platform into the wagon. The milk is collected
by a big wagon, or auto truck, from the cheese factory. Many farmers
around here sell their milk and cream to the cheese factory, and
these platforms are built to make the work easier.”
“Oh,” murmured Violet. She had never had so many questions
answered before without her asking any, and she was in rather a
daze.
“Now run along and play with the others,” her father told her, for
the five little Bunkers were wandering about, looking at things around
the farmhouse.
Mr. Armstrong owned the place, and he came out to shake hands
with Mr. Bunker and Adam North, telling the latter to take as much
water as he needed for the thirsty automobile.
Mrs. Armstrong invited the children in and gave them some
cookies and glasses of milk.
“Aren’t you afraid you’ll spoil your appetites for dinner by eating
now?” asked Daddy Bunker. “It’s eleven o’clock, and we’ll have lunch
about noon.”
“I guess I can eat again,” said Russ.
“So can I.” “And I!” cried the others.
“Bless their hearts!” laughed the motherly Mrs. Armstrong.
While the auto engine was cooling the children ran about and
played tag. Rose thought perhaps her mother and Norah might come
past in the touring car, but Adam said they had probably taken a
shorter way, over a back road.
“I couldn’t go that way because the truck is so heavy,” he
explained. “I have to stick to the hard highways. But we’ll meet your
mother in Westfield.”
“Oh, come on out and see what I found!” cried Margy, running
around the corner of the house.
“What is it?” asked Mun Bun.
“A lot of little pigs in a pen, and they squeal like anything!” Margy
answered.
“Oh, I want to see the pigs! Maybe I can make up a riddle about
’em!” cried Laddie.
There was a rush for the pen, and the children had fun watching
the little pigs stumble about, rooting with their pink noses in the dirt
of their pen for something to eat.
But now the engine was cool enough to travel on, and Mr. Bunker
called the children to come back. Russ was the first to reach the
machine, running up the platform steps ready to help his smaller
brothers and sisters if they needed it.
He peered inside the truck, thinking perhaps the straw would need
spreading out again in a smooth layer, and, as he did so, he started
back in surprise.
“What’s the matter?” asked Rose, who had followed him.
“There’s something in there—in the straw,” whispered Russ.
“You mean one of the children?” asked Rose, for thus she often
spoke of her smaller brothers and sister.
“No, it—it looks like some animal,” said Russ. “Look!”
Rose looked and saw a dark object—clearly an animal—moving
about in the straw.
“Oh, maybe it’s a bear!” she cried.
CHAPTER VII
AT FARMER JOEL’S
Four other little Bunkers were hurrying up the platform steps to get
into the auto truck when Rose and Russ made this discovery of a
strange animal in the straw.
The first impulse of Rose was to run from the animal that, she half
thought, might be a bear that had wandered in from the woods not
far away and had found the warm straw a good place in which to
sleep. The next thought Rose had was for her smaller brothers and
sisters.
Daddy Bunker and Adam North were up near the front of the truck,
getting ready to take their seats, for the engine was now cool and the
radiator filled with fresh water.
Russ had the same idea as had Rose—the desire to save his
brothers and sisters from harm. Seeing them coming up the platform
steps he cried:
“Keep back! Keep back! Don’t come up here!”
“What’s the matter?” asked Laddie.
“There’s something in the straw,” Russ answered.
“It’s an animal!” added Rose. “A big animal!”
“Oh, I want to see it!” cried Mun Bun. “I like animals! Maybe we
can have a circus—this is like a circus wagon!”
The big truck certainly was. But Rose did not intend to have Mun
Bun or the other small ones rush into danger. She stood on the milk
platform at the top of the steps, holding out her hands.
“You mustn’t go in there where the animal is!” cried Rose. “Russ,
can’t you do something?” and her voice was shrill with excitement.
“I’ll get a stick—a stone—something——” panted Russ.
Just then from inside the truck came a stamping sound, as if the
animal were kicking about. At the same time a loud cry echoed.
“What’s the matter?” asked Daddy Bunker, coming back from the
front end of the truck.
At the same time Mr. Armstrong, the farmer, hurried out of a side
gate, calling:
“Did any of you see a little colt? He got out of the pasture, and I
don’t want him to run away. He’s valuable and he may get hurt.”
Before any one could answer the sound of neighing came from
inside the truck, and then Russ knew it was made by the animal he
and Rose had seen standing in the straw.
“Ha! That sounds like my colt!” said Farmer Armstrong.
“It is!” shouted Russ, with a laugh. “He’s in the auto. I’ll get him
out.”
The oldest Bunker boy started to go inside the auto truck, whence
came the neighing, stamping sound of the little horse. But Mr.
Armstrong called out:
“No, lad, don’t go in there. He might kick you. Not that he’s ugly,
but he’s in a strange place, and if you go in he might think you meant
to harm him. Better let me do it. I know how to handle that colt.”
The six little Bunkers, with their father and Adam North, stood at
one side to allow Mr. Armstrong to enter the truck. In he went,
speaking soothing words to the little colt.
“Oh, ho, Bonnie Boy! So you thought you’d hide away and go with
the six little Bunkers, did you? None of that! We want you to stay on
our farm! So you tried to hide in the straw, did you, Bonnie Boy?
Well, come out and I’ll give you a lump of sugar.”
And out of the truck, onto the milk platform, walked Mr. Armstrong,
leading by his halter the colt Bonnie Boy, as he was named.
“Oh, isn’t he sweet?” cried Violet. “How old is he and where is his
mother and has he any brothers and sisters and——”
“Careful, Vi!” laughingly called her father. “Mr. Armstrong isn’t used
to having so many questions fired at him at once.”
“Oh, I don’t mind,” laughed the good-natured farmer. “But this is
the only little colt I have, and his mother is down in the south
pasture. Now you can pet him if you want to,” he added to the
children. “He won’t kick when he’s outside here where he can see
who is near him.”
Up on the platform, around Bonnie Boy, crowded the six little
Bunkers, and the colt rubbed his velvet-like nose against them and
whinnied softly.
“And to think I took him for a bear!” laughed Rose, as she stroked
the glossy neck of the colt.
“Well, he did look like one,” declared Russ.
“Did he walk up the steps?” asked Violet. “I don’t see how he
could.”
“Oh, he’s a great little colt,” said Mr. Armstrong proudly. “He does
all sorts of tricks. One day he got out of the pasture and walked right
into the kitchen where my wife was making a cake. She thought I
was coming in with my big boots on, so she didn’t turn around, and
the colt put his nose on the back of her neck. She—Ha! Ha! She
thought I was kissing her. Oh, ho! ho!” and the farmer laughed
heartily.
Then he led Bonnie Boy down the steps, the little colt making no
trouble at all about treading on them. He was taken back to the
pasture where his mother was waiting for him, doubtless wondering
what had become of him. It was found that there was a break in the
fence, just large enough for the colt to squeeze through, but not
large enough for his mother, or she would have followed him.
The colt had wandered about, coming up to the rear of the house,
and had then made his way to the front, going up the steps of the
milk platform, and so into the big straw-filled truck, which, perhaps,
he thought was a new kind of barn.
“Well, now we’d better be traveling,” said Mr. Bunker, when the
little colt was taken away. “We don’t want to be late in meeting
mother in Westfield.”
Once again the six little Bunkers were on their way.
They were soon at Westfield, a small country town, and when the
big truck drew up in front of the only restaurant in the place there
was the touring car, with Mrs. Bunker and Norah sitting in it, waiting.
“We got here first, and we would have been here before but I had
a puncture and we had to change a tire,” said Mrs. Bunker.
“That’s too bad,” remarked her husband.
“Did you have any adventures?” asked Mrs. Bunker.
“Oh, I should say we did!” cried Violet “There was——”
“The cutest little colt!” broke in Rose, “and he——”
“Was in the straw,” continued Russ, “and when Rose saw him she
——”
“Thought he was a bear,” said Laddie.
Thus several of the little Bunkers had a turn in telling what had
happened.
“That was quite an adventure!” laughed Mrs. Bunker, when she
had been told all that had taken place at the Armstrong farm.
“I’m trying to make up a riddle about the colt, but I haven’t got very
far yet,” said Laddie. “It’s something about straw and a horseshoe
and—oh, well, maybe I’ll think of it after a while,” he said hopefully.
They had a delightful time, lunching in the restaurant, and nothing
much happened except that Mun Bun spilled a glass of water in his
lap and got wet. But as it was a warm day it didn’t matter.
Margy discovered a little kitten wandering about the eating place,
and she insisted on giving pussy some of her milk. The result was,
Margy’s hands not being very steady, that she upset a glass of milk
on the floor.
But, as the restaurant keeper said, it didn’t matter, for the floor
needed mopping anyhow.
Once more the little party started off in the two automobiles, Mrs.
Bunker and Norah in the touring car taking the lead. In about an hour
more they were at Cedarhurst. Then very soon, turning down a quiet
country road, the six little Bunkers saw in the distance a white
farmhouse in the middle of broad fields—a farmhouse with barns
and other buildings around it.
“That’s a dandy place!” exclaimed Russ.
“Lovely,” murmured Rose.
“Is that where we’re going to stay?” asked Violet.
“Yes, that is Farmer Joel’s,” her father answered.
A little later the little Bunkers were fairly tumbling out of the auto
truck in their eagerness to see all the sights. Mrs. Bunker and Norah
were already at the place.
“My, but I’m glad to see you all!” cried Farmer Joel, and the six
little Bunkers needed but one look at him to make sure they would
love him, for Mr. Todd was a kindly man. And his sister, Miss Lavina,
was just as loving and kind.
“Well, I’m glad you’re here,” said Miss Todd. “Now that I see so
many lovely children it makes me want to stay and play with you. But
brother Joel says I need a vacation, so I’m going off on a visit.”
The big farm was the most delightful place in the world at which to
spend a vacation. As Adam North had said, there were broad fields
—some green pastures, and others where hay and grain were
growing. There were two orchards, one of apple trees and another of
peach trees.
“And don’t eat apples yet, for they aren’t ripe,” warned Farmer Joel
as the children, putting on their old clothes, started out to explore
things.
“I want to see some horses!” cried Laddie.
“I want to go where the sheep are,” Mun Bun said.
“So do I,” chimed in Margy.
“I’ll go to the kitchen to help mother,” offered Rose, but her mother
said:
“No, you run out and play now. Norah and I can manage the work
all right. Later on if you want to help you may.”
So Rose went out with Russ and the others.
“There’s a brook, Russ!” called Violet, as she caught sight of the
sparkle of a little stream.
“That’s good. Then I’ll make a water wheel and a mill,” said Russ.
He and Laddie were looking at the brook, poking in sticks to find
out how deep it was and making ready to build the dam for the water
wheel, when suddenly they heard the voice of Rose crying:
“Oh, drive him away! Make him go away! Oh! Oh! Oh!”
“What’s that?” asked Russ, looking up.
“It was Rose,” answered Laddie. “I guess——”
The loud barking of a dog interrupted him, and Rose cried again:
“Oh, Russ, come and drive him away!”
CHAPTER VIII
IN THE HAY
Russ looked up from the dam he was making for the water wheel.
He could not see Rose. Nor could Laddie, who was helping his
brother make the little mill pond. But Rose kept on yelling and the
dog kept on barking.
“Oh, somebody please come!” cried Rose.
“I’m coming!” shouted Russ.
He leaped up, followed by Laddie, and, as they turned around a
clump of bushes and looked down the brook they saw Rose standing
with her back against a big tree while in front of her, leaping about
and barking loudly, was a large brown dog.
“Oh, Russ! Russ!” begged his sister, as she caught sight of him
and Laddie. “Come and drive this dog away! He wants to bite me!”
“I’ll drive him away!” declared Russ.
“And I’ll help,” added Laddie. “He’s a bad dog!”
Before the two brothers could reach their sister there came
running toward Rose another boy. This boy had a freckled face and
red hair.
“Don’t hit my dog!” cried this red-haired boy. “He won’t hurt you.
Hi, Jimsie!” called this new boy, “behave yourself! Down! Quiet! Quit
your barking!”
The dog looked around at the voice, wagged his tail to show that
he was friendly, and stopped barking. Just then up rushed Russ and
Laddie with sticks in their hands. Rose also had a stick which she
had raised toward the dog, but she had not hit him.
“Don’t beat my dog Jimsie!” begged the strange boy. “He didn’t
mean any harm.”
“What did he try to bite my sister for?” demanded Russ, who was
angry.
“Oh, he didn’t exactly try to bite me,” said Rose. “He just barked a
lot and he wouldn’t let me get away, and I was afraid he’d bite me.”
“Jimsie wouldn’t bite anybody,” said the boy, whose name was
Ralph Watson. He lived on the farm next to that of Mr. Todd.
“Well, then, what made him bark at my sister?” asked Russ.
“’Cause she had a stick,” answered Ralph.
“Does he bark at everybody who has a stick?” asked Laddie. “If he
does why doesn’t he bark at Russ and me—we have sticks?”
“I guess he will bark at you as soon as he sees you have sticks,”
Ralph answered. “I’ll try him.” He moved around until he stood
beside Russ and Laddie, and as the dog’s eyes followed his young
master Jimsie caught sight of the two Bunker boys and the sticks
they held. At once Jimsie began to bark, greatly excited.
“There! I told you!” cried Ralph.
“What makes him bark so just because he sees a stick?” asked
Russ. “Does he think we’re going to hit him with ’em? I wouldn’t hit
any dog, unless he was going to bite somebody.”
“No, Jimsie doesn’t think he’s going to be hit,” explained Ralph.
“He just wants you to throw the sticks in the brook so he can jump in
and bring ’em out. Always when he sees any one with a stick he
thinks they’re going to play with him and throw the stick into the
water. I guess he thought you were going to play with him,” said
Ralph to Rose, “and when you didn’t—why, he just barked.”
“Oh, I see!” exclaimed Rose, with a laugh, for she was over her
fright now. “That was his way of asking me to throw the stick in the
water.”
“Yes,” answered Ralph with a smile that lighted up his jolly,
freckled face. “Sometimes he barks like anything when I take a stick
and don’t throw it in for him to bring out.”
And, indeed, Jimsie seemed very much excited now because
Russ and Laddie would not toss their sticks into the brook. And at
last, to please the dog, Russ tossed his stick in.
Instantly Jimsie plunged in after it, swimming out and bringing the
stick back to shore, dropping it at the feet of Russ as if asking that it
be thrown in again.
“Oh, isn’t he cute!” exclaimed Rose.
“He’s a good dog!” declared Russ.
“Will he bring out a stick for me?” asked Laddie.
“He’ll do it for anybody,” answered Ralph.
“I’ll try it,” said Laddie.
In he tossed his stick, and in plunged Jimsie after it, bringing it
back to shore, which made Laddie laugh. Then Jimsie gave himself
a shake, sending a shower of drops all over Rose, who was near
him.
“Oh!” cried the little Bunker girl in surprise.
“Jimsie, don’t you know any better than that?” cried Ralph, in a
scolding voice. “Shame on you!”
“Oh, I don’t mind,” said Rose quickly. “This is an old dress and
water won’t spot it. There, go in and get my stick!” she ordered, as
she tossed hers into the brook. “You wanted me to throw it before,
but I didn’t know what you meant by your barking. Now get the stick.”
Jimsie quickly brought the stick to shore for Rose. Then Ralph
tossed one in and his dog got that. Russ and Laddie wanted to try
their sticks over again, but Rose said:
“Oh, the poor dog will get tired! Don’t make him do so much.”
“He likes it,” Ralph said. “He’d chase sticks all day, I guess, if
you’d throw ’em for him. But maybe it’s time he quit. I have to go
after the cows, anyhow.”
“Where are they? Could we go with you?” asked Laddie eagerly.
“Do you live around here?” Russ wanted to know.
Ralph Watson told his name and where he lived, but he said it was
a long distance to the cow pasture where he had to go, and he
added that the mother of the Bunker children might not let them go.
“I’ll take you to-morrow if you want to come, though,” Ralph
promised.
“Then we’ll go,” said Rose.
Then, in answer to a question, she told the others that she had
been walking along the brook looking for watercress, of which Daddy
Bunker was very fond. Rose was using the stick to poke aside the
bushes on the edge of the brook when suddenly Jimsie had sprung
out at her, driving her back against the tree, where she had stood,
afraid to move while the dog barked so furiously.
“If I had only known he wanted to play I’d have played with him,”
finished Rose, with a laugh. “But I thought he was a savage dog.”
“Oh, Jimsie is never ugly,” said Ralph. “He barks a lot, but I guess
that’s because he has to do it when he helps me drive the cows.
Well, I’ll see you again,” he added, as he started away with his dog.
“He’s a nice boy,” said Rose, when he was out of sight.
“I’d like to have that dog,” remarked Russ.
“I think—now maybe—I guess I have a riddle about a dog,” began
Laddie, but before he could ask it, or even before he could think
what it was, yells and screams came from another part of the brook.
“That’s Mun Bun!” exclaimed Rose.
“Sounded like Margy, too,” said Russ.
“Maybe they’ve fallen into the water,” suggested Laddie.
Just then Violet was heard asking:
“Oh, what did you want to go and do that for? Now you have gone
and done it! Are your feet wet? Did you get hurt, Mun Bun?”

Effective Devops Building A Culture of Collaboration Affinity and Tooling at Scale Early Release 1 (Early Release) Edition Jennifer Davis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Effective Devops Building A Culture of Collaboration Affinity and Tooling at Scale Early Release 1 (Early Release) Edition Jennifer Davis

Uploaded by

Copyright:

Available Formats

Effective DevOps Building a Culture of

Collaboration Affinity and Tooling at

Building Microservices, 2nd Edition (Early Release, Raw

Building Generative AI Services with FastAPI (Early

Programming Rust, 2nd Edition (Early Release) Jim

Docker in the Trenches Successful Production Deployment

Architecting HBase Applications A Guidebook for

SVG Colors Patterns Gradients Painting Vector Graphics

LLMs and Generative AI for Healthcare (Early Release)

Kafka: The Definitive Guide, 2nd Edition (Early

Jennifer Davis & Katherine Daniels

Editor: Brian Anderson Proofreader: FILL IN PROOFREADER

February 2016: First Edition

Revision History for the First Early Release Edition

See http://oreilly.com/catalog/errata.csp?isbn=9781491926307 for release details.

3. Collaboration: Individuals Working Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4. Hiring: Choosing Individuals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5. Tools: Selection and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

<section data-type="sect1"> <aside data-type="sidebar"> <h5>Early Release Edi‐

The History of Devops

The Advent of Software Engineering

10 | Chapter 2: What is Devops?

• defining and measuring success

The History of Devops | 11

The Age of the Operating System

12 | Chapter 2: What is Devops?

The Beginnings of a Global Community

The History of Devops | 13

Trade Secrets and Proprietary Information

The Age of Applications and the Web

14 | Chapter 2: What is Devops?

The History of Devops | 15

16 | Chapter 2: What is Devops?

Foundational Devops Terminology and Concepts

Foundational Devops Terminology and Concepts | 17

Figure 2-1. A Visual Representation of the Waterfall Model

18 | Chapter 2: What is Devops?

Foundational Devops Terminology and Concepts | 19

20 | Chapter 2: What is Devops?

Is Devops Just Agile?

Community of Practice and Community of Interest

Foundational Devops Terminology and Concepts | 21

22 | Chapter 2: What is Devops?

The Old View and the New View

Foundational Devops Terminology and Concepts | 23

24 | Chapter 2: What is Devops?

Foundational Devops Terminology and Concepts | 25

In the devops community, there is a big emphasis placed on having post-mortems

26 | Chapter 2: What is Devops?

Devops: Adding it All Up

Devops: Adding it All Up | 27

Common Devops Misconceptions

Devops only involves developers and system administrators.

28 | Chapter 2: What is Devops?

You might also like