构建大规模协作与工具化的DevOps文化

下载需积分: 9 | PDF格式 | 6.78MB | 更新于2024-07-20 | 156 浏览量 | 举报

1 收藏

"Effective DevOps" 是一本由 Jennifer Davis 和 Katherine Daniels 合著的书籍，主要探讨如何在大规模环境中构建协作、亲和力和技术工具的文化，以实现高效的 DevOps 实践。在这本书中，作者深入剖析了 DevOps 的核心理念，强调了团队之间的紧密合作、共享责任以及利用合适的技术工具在开发和运维之间建立桥梁的重要性。DevOps 是一种旨在缩短开发周期并提高软件质量的持续集成和交付方法论。它提倡通过自动化流程、跨职能团队的合作以及对业务价值的关注来促进快速反馈和持续改进。书中可能会涵盖以下几个关键知识点： 1. **文化转型**：DevOps 不仅仅是一种技术实践，更是一种组织文化变革。作者可能会讨论如何推动组织内部的文化转变，鼓励开放沟通、信任和透明度，以减少部门间的隔阂。 2. **协作与团队建设**：有效的 DevOps 需要开发人员、测试人员和运维人员紧密合作。书中可能提供关于如何建立跨职能团队，以及如何通过共享目标和共同承担责任来提升团队效率的建议。 3. **自动化**：自动化是 DevOps 的基石，涵盖了代码构建、测试、部署和监控等环节。作者可能会分享关于如何设计和实施自动化流程的最佳实践，以减少手动错误并提高效率。 4. **持续集成与持续交付(CI/CD)**：CI/CD 流程能够确保代码的快速迭代和稳定部署。书中的内容可能包括设置 CI/CD 管道的步骤，以及如何通过自动化测试来保证代码质量。 5. **监控与反馈**：实时监控系统性能和用户反馈是 DevOps 中不可或缺的部分。作者可能会讲述如何实施有效的监控策略，并通过日志分析、指标收集和警报系统来获取及时的反馈。 6. **安全性**：在 DevOps 中，安全不应被视为一个孤立的阶段，而应融入整个软件开发生命周期。书中可能涵盖如何实现安全性作为默认设置，以及如何在快速交付的同时保持系统的安全性。 7. **工具链**：DevOps 涉及多种工具，如版本控制系统、自动化构建工具、容器化技术、持续集成服务器等。作者可能会讨论如何选择和整合这些工具，以构建一个支持高效 DevOps 工作流的工具链。通过阅读 "Effective DevOps"，读者可以了解到如何在大规模的组织中成功地实施 DevOps，从而实现更快的软件发布周期、更高的质量和更强的业务敏捷性。这本书对于想要提升团队效率、优化软件开发流程或正在进行 DevOps 转型的 IT 专业人士来说是一份宝贵的资源。

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

The History of Devops | 15

www.it-ebooks.info

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.

16 | Chapter 2: What is Devops?

www.it-ebooks.info

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

www.it-ebooks.info

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‐

Foundational Devops Terminology and Concepts | 19

www.it-ebooks.info

剩余154页未读，继续阅读

雨一直下315

粉丝: 1

构建大规模协作与工具化的DevOps文化

2017 DevOps 现状调查报告（官方中文版）

Effective DevOps Building a Culture of Collaboration, Affinity, and Tooling epub

Effective DevOps Building a Culture of Collaboration, Affinity, and 无水印原版pdf

打造协作文化：Effective DevOps 实践指南

Effective-DevOps-with-AWS:Packt发布的《使用AWS的有效DevOps》

Effective-DevOps-and-Development-with-Docker-V-:Packt出版的《有效利用Docker（V）进行DevOps和开发》

OReilly.Effective.DevOps.Building.a.Culture.of.Collaboration.Affinity.and

Python for DevOps Learn Ruthlessly Effective Automation.pdf

Devops_Learning:Python基本代码

Implementing.DevOps.on.AWS.epub

最新资源