我发现最引人入胜的是，Google基本上重新发现了系统管理员工作中真正重要的部分，并将功能开发人员和可靠性角色之间的契约制度化了。而不是让功能开发人员觉得他们在操作要求方面没有发言权，也不是让可靠性人员与不稳定的状态作斗争：正确地制定契约意味着每个人的声音都能被听到。与DevOps相比，尽管DevOps是在这本书出版后才出现的，但在当时很流行；这导致了系统管理员角色的定义变得模糊，要么是：* 一个实践敏捷的系统管理员（顺便说一下，这是最初的定义）* 一个具备足够操作系统技能来处理警报的软件工程师（这是比较流行的定义）* 一个由系统管理员和软件开发人员组成的团队，他们之间没有任何界限（每天部署10次以上的风格）。每个人对DevOps都有自己的定义。因此，当SRE（站点可靠性工程）清晰地出现时：系统管理员是必要的，停止试图将所有事情都推给一个人，这是如何解决团队之间紧张关系的方法：这让人耳目一新。
源讨论谷歌的SRE书籍（2017年）原帖 84 条评论 · 导入时统计把你的经验，加入这段讨论。
我认为这不是书中对SRE角色的描述。它改变了系统管理员和开发人员之间的界限，使开发人员在决定其软件的运行/发布操作参数方面有更大的自由度，但也使SRE能够在接手的软件不符合使实际操作大部分自动化的推荐模式时进行反驳。
完整原文最初，系统管理员指的是精通C语言的Unix老手，他们能够编写和实现诸如Kerberos之类的东西。然后在90年代到2000年代，这个词主要指的是在大型企业中点击Active Directory和组策略的Windows管理员。"系统管理员不会编程"这个说法来自那个时期以及2010年代初，当时所有酷的初创公司都在Linux上构建，可用的系统管理员大多都是Windows专家。然后DevOps出现，试图让那些在Linux上有些涉猎的Windows系统管理员进入现代开发实践，而SRE则试图用现代软件开发实践来复兴旧式的Unix老手风格。
完整原文这可能是在80年代和90年代系统管理员的含义，但现在不是了。我不会将自己，一个SRE-SE，描述为系统管理员，因为这会描述一个主要工作是操作软件并迭代配置的人。 另一方面，SRE-SE是软件工程师，他们只是专注于与系统相关的软件，而SRE-SWE则是能够深入编译器级别问题和优化的人。两者都编写应用代码、进行分析并编写策略。今天的系统管理员会在这样的团队中显得格格不入。
完整原文* SRE是使用Go语言的系统管理员 * DevOps是使用Python语言的系统管理员 * 系统管理员是使用Perl语言的系统管理员（从Twitter上偷来的，找不到来源）
完整原文我认为你是对的，但我想讲一个故事，其中敏捷团队领导认为DevOps意味着“开发人员操作”，换句话说就是开发团队。 有时候你只能摇头。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。