在公司成立之前，我们团队就曾经末尾运用 DevOps 实际，而我团体，早在十年前，在另一家公司担任系统管理员的时分，就第一次接触到了这种新颖的思想方式。那个时分，还没有 DevOps 这种标准说法，但是事先实际的人也本人探索出了一些相关的概念与准绳。

继续集成；

自动交付；

每位团队成员都对产品负有责任；

与客户直接沟通；

搜集并剖析业务 / 运用顺序目的；

阐明文档等；

后来证明以上这一切都是对矫捷倡议中各项实际的逻辑扩展，而催生出这些办法的温床，则是开发者不再单纯为本地主机编写代码这一基本前提。

Atlassian 提出的 DevOps 原理

由 Atlassian 提出的 DevOps 形式直到明天依然十分重要。从本质上讲，其代表着产品开发与交付的现代化周期，同时涵盖产品启动之后的运作流程。

1. 前 DevOps 时代：管理员与开发者之间的鸿沟

长久以来，产品的运营与开发任务彼此割裂。这条鸿沟的一端是勤劳朴实的开发人员，另一端则是开发者眼中那些似乎行尸走肉般的系统管理员。系统管理员不参与开发，也不会与开发团队沟通，他们通常只是直接拿到代码包，然后尝试在某个位置加以运转。每一次运转尝试都痛苦万分，管理员们需求花几天时间渐渐查看日志、寻觅种种难以了解的错误、剖析数据库查询、堕入无量无尽的 strace 进程等。而很多时分的理想都证明，只需求定义一项新的环境变量或许添加一个新参数，成绩就能迎刃而解。但遗憾的是，开发者历来不会、也没无时机把状况告知管理员，后者独一了解的就是产品的称号及其用什么言语编写而成……

2. 十年前的“DevOps”任务

十年之前，我刚末尾在团队中担任管理员，事先的公司思想比较灵敏，我不像《IT 狂人》的剧情那样被放置在地下室某个阴暗的小房间里，而是在开发者当中拥有了本人的办公桌。从那一刻末尾，我也踏上了本人的 DevOps 工程师之旅。

在公司的任务中，我很快看法到，虽然知识和技艺都很重要，但从沟通及运营角度审视并影响产品的才能更值得关注。我有权提出异议、表达本人的担忧，并在距离最终交付还有很久的时分就及时向开发者传达观念或提示他们调整编写办法。这才是真正的管理员，他们不该被“囚禁”在地下室里！

理想很快证明，将产品的设计、开发与运营等元素停止综合审视，确实可以带来庞大的收益。只要每一团体都对产品担任，并清楚看法到产品将在怎样的消费环境中运转时，开发流程将真正与消费流程融合起来。这一切如古人们习以为常的思绪，在事先不啻为一种文明冲击——开发者与管理员真正携起手来，天下再无难事！而这一切，都是被沟通鸿沟所严重割裂的传统流程所无法完成的。

但假设 DevOps 只是一种矫捷开发流程，而且在其中引入了开发阶段的概念，那么 DevOps 工程师又是干什么的？DevOps 世界中的中心职责终究是什么？这就带来了另一个重要成绩：DevOps 团队的理想首领应该是谁？

团队担任人的角色可以由中层专业人士担任，而且对职位或背景没有特别明白的要求（可以是开发人员、管理员甚至是质量保证人员）。DevOps 之所以存在，主要目的就是填补产品在继续集成、交付以及运转周期中的种种空白。

从团体的客观角度动身，我以为 DevOps 指导者最好具有管理员背景（而非选择所谓的「技术主干」）。以此为基础，他 / 她可以将与数据库晋级、配置管理或许一切其他令开发者专心或懊恼的底层基础设备相关要素剥离出来。这里，我还要提出另一项管理员有更适宜担任 DevOps 指导任务的观念：随着产品的开展与成熟，DevOps 团队也将随之扩展，因此需求投入的时间及精神会同步增长。假设指定开发人员指导您的 DevOps 团队，其将很难全神贯注继续处置开发任务。最后一个理由：管理员更易于上手 DevOps 任务，所以起步速度会更快一些。

3. DevOps 工程师该懂些什么？

DevOps 工程师们应该懂点什么，又该会做些什么？本文整理了一份 DevOps 工程师的技艺清单，当然罗列的能够不残缺，只涵盖工程师们应当具有的部分中心技艺。

矫捷开发准绳

这也是现代开发世界中最重要的技艺之一（特别是在远程协作开发场景之下）。其中不只包括区分 Kanban 与 Scrum 间的差异，同时也要求我们可以与团队顺畅沟通、了解客户价值、跟踪时间进度，以及整理出易于了解的任务日志、独立报告与明晰阐明文档的才能。

自动化 + 万物即代码

大家应该尽快摆脱手动操作的困扰。时至昔日，简直一切日常任务都对应着自动化工具。假设找不到现成的工具，您也可以运用 Python 及 bash 自行编写。例如，假设需求创立虚拟机镜像，请运用 Packer。假设需求配置 10 台以上的主机，请运用 Ansible。假设您在 Google Cloud Platform 中创立 Kubernertes 集群，或许需求在 Amazon 上运用 CDN，请运用 Terraform 以简化操作流程。总而言之，从经过网络加载新的裸机效劳器到在现有集群中部署新容器，一切都应以自动化方式停止。另外，您编写的代码应该具有可复制性与幂等性，提交内容必须经过跟踪顺序的审核，且严厉遵照以上要求。

云与混合架构

目前，我们发现大少数企业都不会只运用一家云效劳供应商（为了避免供应商锁定成绩）。没错，一切不该复杂粗犷地交给云方案处置，我们可以将效劳中的不同部分运转在 AWS、Heroku 以及其他 IaaS、PaaS 与 SaaS 之上。请努力找到最理想的处置方案，并保证可以在特定时段内完成不同平台之间的效劳迁移。另外，也别忘了之前提到的自动化准绳，自动化水平越高、迁移难度就越低。

可扩展性与高可用性要求

最重要的是看法到企业可以在特定时段内接受怎样的停机与数据丧失影响。明白这一点之后，大家会发现长达 24 个小时的资源停机假定将毫有意义。另外，资源哪怕只宕机一个小时，形成的损失就能够高于一整年的残缺热备份效劳运用成本。借助云效劳与容器化技术，扩展系统规模变得愈发轻松。但是，基础设备与效劳本身也需求为这种灵敏扩展才能做好预备（这里再次向本地对象存储开炮，这简直就是费事的终极本源）。

监控与警报

(责任编辑：admin)