SRE，DevOps，PE的运维本质和价值都是为产品和业务服务(2)

关注风险,但没有绝对的安全.DevOps的经典书籍《凤凰工程》里有一段情节,有个做审计的人总是特别郁闷,因为总觉得IT的人不按审计的要求去修复所有问题,会出非常大的问题.但是最终的结果是审计成功通过,因为公司里财务的人通过业务上的检查,解决了发现的安全问题,也就是说即使IT上存在一些问题,也可以通过业务的方式弥补,达到最终的安全.DevOps告诉我们,你要关注风险而不简单是安全,在避免风险的前提下,制度不应妨碍业务的发展和交互.另外,也要通过技术提升安全,简化流程,尽量实现自动化.设计流程很容易,很多公司里面都有特别多的工单,但是你要想你的工单是不是有作用?比如说是不是所有的项目的上线都需要安全的人审核,如果能自动判断没有风险的话,能否自动化流转?

DevSecOps和DevOps一样,也要加强人与人之间的沟通、协作,负责安全的人应该和开发、运维、测试人员一起防范风险.

浅谈SRE

谈谈SRE,SRE需要负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作,包括工程研发、日常运维以及监控响应方向的工作.

深究PE

PE起源

重点分享我正在做的PE是什么,先介绍一下PE的起源.大家比较认可的是从雅虎开始流行的,国内最大的团队就是阿里的PE团队,后来受阿里影响很多公司也设了PE职位.PE这个词有的叫产品运维工程师,有的叫业务运维工程师,也可以直接认为就是应用运维团队,简单来说就是负责业务或应用相关的一系列工程上的事务.

这是Facebook的招聘描述,PE既拥有软件也拥有系统方面知识的工程师,要保障Facebook 的服务平滑的运行,有足够的容量满足未来的规划.这也是刚才说的Facebook很强调两点：一个是视野,一个是影响力.技术人要有视野,能预见公司未来的业务发展,根据视野做设计.一方面要保证服务平滑运行,另一方面要满足未来的容量规划,以此设计基础组件,要有长久规划设计的能力.每个Facebook 产品,包括基础设施,都有PE的人.

听阿里毕玄老师说,阿里的PE团队打散到不同的BU业务单元里.大家要根据自身的情况考虑,Facebook 团队比较大,每个大团队都有两个PE的人跟进,他们有广阔的视野和经验,背景也比较好,从整个团队来看,既有新人也有老手,组成了多样化的团队.

除了写代码,PE也要会写文档.做运维的人一定不要抗拒写文档,不管在哪里,文档都很重要.好的文档能把事情描述清楚,给别人去看,传播给更多人,而不只是在自己的脑子里面.PE要做容量规划,像京东每年都有两次大促,618大促,双十一大促,PE要规划容量和性能能否够满足业务的发展.PE需要调试处理最困难的问题,所有运维都知道调试排查问题(Trouble Shooting),但是能做好的很难.很多公司做问题处理的时候,如果有乙方的支持,只要问题能解决,公司的人就不去想是问题的原因.

我们需要反思,再去自我提高,好的PE问题排查和总结范围的能力都很强,简单的问题也可以找到深层次的原因并做长期的提升改进.PE要加入到值班轮转里,在值班的时候处理问题.PE要做产品协调员,和工程师团队一同协作,这和SRE里相关的部分很像.

PE会和很多人打交道,这点对其他职业也是通用的.我很强调人与人之间的沟通协作,PE是一个协调员的角色,要和PM、产品经理、程序员、网工,或者SRE沟通,与各个组协调把事情做好.我招PE的时候,很注意软技能,如果软技能方面有问题,只想做技术,很多事情都很难处理,后面的风险会更大.对于个人,不管是运维还是其他职位,想更好的发展都应该提升软技能方面的能力,更多地与合作伙伴、同事共同协作,大家达成一致的目标,协作完成任务.

目标部分再说一下,管理者还要评估PE的绩效,保证业务正常运转,这也是管理者的一项重要工作.PE或应用运维工程师如何做发展计划?如果不转型,还是按PE方向发展,我觉得发展为架构师是很好的规划.

总结一下我对PE的定位.首先,PE应该是服务的第一响应者,有问题要马上处理.大家要有这个意识,有问题要能快速处理,这也要靠公司机制去保证,并不只是靠人.人不可能7*24小时处理问题,但是机制可以保证,包括轮班,一线二线的人分离任务,在保证核心的人不要太累的同时处理问题.性能分析师,利用有限资源承载更多的业务,京东每次大促前都要做全链路压测,做评估、扩容,先做性能分析,然后在进行容量规划.系统管理员是基本功,要懂操作系统,懂网络,也要能写Code,开发工具等等.开发工具并不要求是很大的平台,可以和专业开发人员一块去开发,解决问题就好.最后,产品工程协调员,加强人与人之间的沟通.

落地PE实践及心得

如何结合组织架构设计技术架构

三个角色的定义都说完了,再说说如何结合组织架构设计技术架构,这里有很经典的康威定律原则——组织结构会影响技术架构,技术架构会影响到运维架构.康威定律很重要的一点是说,假如团队里有N个人,每个人都要跟N-1个人去沟通,团队越大沟通成本越高.

如何设计结构降低沟通的成本?传统模式下很多公司都是职能型的团队,开发、运维、测试属于不同的职能团队,开发的人写好代码给运维的人上线就行了.在新的互联网公司中,除了传统的职能型团队以外,还有实施矩阵式管理,做单元化、BU化组织架构的,这样可以降低沟通协作的成本.

我之前在人人网带的团队有7、8个人,现在的团队比较大,有差不多20人.20人的团队怎么设计结构?我把业务线打散到两个不同的业务组里,这里也有一个2-pizza team的原则.假如两个pizza都喂不饱团队的时候,团队的沟通成本其实是很高的,管理也有难度.要把团队打散划分成更小的线,8人以内是比较合适的.

（编辑：ASP站长网）