在DevOps中有没有更好的时间？电视节目如“兴趣人物”和“先生机器人“正在越来越好地显示开发人员的实际工作，使用大量的工作代码。像迈克尔·曼（Michael Mann）的“黑帽”（Blackhat）这样的电影（2015）在几个场景中赢得了Google安全团队的DevOps准确性的赞誉。环顾四周，您将发现DevOps文化过滤出来的更广泛的社会元素，如各界人士讨论他们的正常运行时间或快速接近的代码锁。
另一方面，DevOps中最大的棘手也许是开发人员和运营团队通常不会很顺利。开发人员希望在非常紧张的时间表下赶上前期的一些开创性的代码，而运营团队则尽量减缓每个人的下落情况，以发现事故或恶意行为者的系统性风险。两队都希望能够获得更好的用户体验，但到达那里的时候，就会成为一种权力斗争。
将DevOps融合在一起的梦想是对于可以半开半场的人。这种分裂的愿望正是SRE（现场可靠性工程师）的重点。
定义SRE
在介绍SRE这个术语时，Google的工程副总裁Ben Treynor说：
“当您要求软件工程师设计操作功能时，会发生什么。SRE从根本上做了一些运维团队历来做的工作，但是使用具有软件专业知识的工程师，并且就这些工程师固有地倾向于并且有能力将自动化替代为手动劳动。“
回到2010年，Facebook SRE Mark Schonbach解释了他这样做：
“我是站点可靠性工程师（SRE）的小团队的一部分，这些工作人员日夜工作，以确保您和全球其他4.0亿用户能够访问Facebook，网站加载速度快，所有功能正在... ...我们经常在飞行中擅长工具，帮助我们管理和执行复杂的维护程序，这些程序是世界上最大的，即使不是最大的memcached足迹。我们开发自动化工具来配置新服务器，重新分配现有服务器，以及检测和修复不正常行为的应用程序或服务器。
SREs来自哪里？
可靠性工程是一个从业务世界发展而来的概念，已经有100多年了。第二次世界大战后，IEEE成立了可靠性协会，与电子系统密切相关。十年来，五十九（99.999）成为应用绩效管理的黄金标准。该标准导致创建了一类操作专家，他们知道足够的代码来恢复站点，并将最后的稳定版本尽可能快地重新投入生产。
Treynor解释了在谷歌创造这个新类别的动力，他的典型的幽默幽默：“您通常在操作角色看到的与工程角色相反的一件事是，不仅在责任方面，而且背景和的词汇，最终的尊重。对我来说，这是病态。“
SREs使用哪些工具集？
对于SRE，稳定性和正常运行时间的首要任务。但是，他们应该能够承担起责任，并将自己的方式编入危险之中，而不是添加到开发团队的待办事项列表中。就Google而言，SRE通常是软件工程师，其中有一层网络培训。通常，Google软件工程师必须表现出：
Google自己的Golang和OO语言，如C ++，Python或Java
一种辅助语言，如JavaScript，CSS和HTML，PHP，Ruby，Scheme，Perl等
高级领域，如AI研究，加密，编译器，UX设计等
与其他编码人员联系
除了这些精通之外，Google的SRE必须具备网络工程，Unix系统管理员或更多通用网络/操作技能（如LDAP和DNS）的经验。
SRE的关键作用
艾默生网络能源公司（Emerson Network Power）的一份报告显示，停机时间每小时耗资约30万美元。最明显的影响是流量尖峰下降，电子商务网站在最近的AppDynamics白皮书中被覆盖。然而，Treynor还指出，标准开发商与操作系统的摩擦力如何以其他方式成本高昂。经典的冲突从功能更新发布之前的操作提供给开发人员的支持清单开始。当用户喜欢新开发的功能时，开发者赢得越早越好。同时，在正常运行时间报告中最多有9次操作时，操作胜出。所有变化带来不稳定;你如何调整自己的兴趣？
Treynor的答案是对那些与用户满意度指标有关的人的救济，但并不是那些有心脏病的人。他说，
“100％是基本上所有的错误的可靠性目标。也许起搏器是一个很好的例外！但是，一般来说，对于您可以想到的任何软件服务或系统，100％不是正确的可靠性目标，因为没有用户可以告诉100％可用的系统之间的差异，假设有99.999％的可用性。因为通常情况下，您正在运行的用户和软件服务之间存在许多其他事情，这些边际差异会丢失到其他一切可能出错的噪点上。“
这种反应将焦点从针对用户期望的准确代理的具体正常运行时间指标转移到基于市场现实的可靠性指标。Treynor解释说，
“如果100％是系统错误的可靠性目标，那么系统的正确的可靠性目标是什么？我建议这是一个产品问题。这不是一个技术问题。考虑到他们支付多少，无论是直接还是间接，以及他们的替代方案，用户都会满意的是什么。
谁雇用SREs？
简单的答案是“每个人”，从软件/硬件巨头如苹果到金融门户如晨星到非营利机构，如劳伦斯伯克利国家实验室。伯克利是一个组织的一个很好的例子，既是能源研究的前沿，同时也保留着一些非常古老的遗留系统。确保几代技术的可靠性是一个巨大的挑战。以下是伯克利实验室负责SREs的工作：
Linux系统管理技能来监控和管理由控制室桥梁负责的系统的可靠性。
开发和维护用于支持NERSC中HPC社区的监控工具，使用C，C ++，Python，Java或Perl等编程语言。
在设计软件，工作流程和流程方面提供改进组监控能力的输入，以确保NERSC和ESnet提供的HPC服务的高可用性。
支持测试和实施新的监控工具，工作流程和新功能，为生产中的系统提供高可用性。
通过管理组件升级和更换（软件，硬盘，卡，电缆等）来协助数据集群的直接硬件支持，以确保节点有效地返回生产服务。
帮助调查和评估新技术和解决方案，推动集团的能力向前发展，超越用户需求，并说服受到激励的员工转型创新，持续改进。
与维基百科的在线公司相比，技能简介，其中SRE任务往往不那么技术性和外交性较强：
提高自动化，工具和流程以支持开发和部署
与工程团队建立深厚的合作伙伴关系，致力于改善用户体验
参加冲刺规划会议，并支持部门间协调
排除站点中断和性能问题，包括通话响应
帮助提供系统和服务，包括配置管理
支持能力规划，现场演示分析和其他分析
帮助一般操作问题，包括机票和其他正在进行的维护任务
在过去一年中，出现了更加战略性的决策层面的转变，反映了客户请求和故障转移程序日益增加的自动化。即使像IBM这样的传统公司，由于物联网议程的推进，SREs也可以使用一些最新的平台。例如，爱尔兰IBM的一个SRE开放课程需要OpenStack Heat，Urban Code Deploy，Chef，Jenkins，ELK，Splunk，Collect D和Graphite等方面的经验。
SREs如何变化
现在的网络世界和现在十年前的SRE进入现场是截然不同的。此后，移动已经重新定义了开发周期，轻松访问基于云的数据中心已将微服务引入主流IT基础架构。Startups定期使用Rest和JSON作为移动应用程序的首选协议。根据精益创业的原则，DevOps通常是小型，更集中的团队，作为集体SRE。
您会发现开发和运营之间有更多的协作和更少的冲突，只是因为持续的交付模式将开发和运营的责任分解为一个周期。DevOps这个术语可能会消失，因为两个不同的部门合并在新的世界中，其中UX是一切，更新可能会每周推出。无论在任何给定的SRE工作描述中有多少个9，这个职业生涯路径似乎为您提供最高的工作安全可靠性。
