樱桃沟夹事

昨日接着球子校友返校的机会，我作为家属也参观了帝都唯一市属211高校北工大。

昨日刚好又是高考志愿接待日，好像还是有很多学生和家长来参观的。所以学校里到处都是类似这样的横幅。但我也明白为什么这个横幅上那么多孔呢？

在我认识球子的时候，北工大还是号称帝都四大染缸之一，我们也都看过该校学生孙睿写的一本网络小说《草样年华》。所以上面横幅的这些孔又是这些学生搞的呗。

北工大学生的标志性纪念品就是工大锤，球子说一直在家里，但是我好像从来没见过。而工大锤就是从下面这个学院弄出来的。

区别

在大型企业中都会有SRE的专职部门，负责整个系统的可用性，但是在中小企业中一般不会设置这种部门，可能会有个把人在运维组织里做SRE相关的事务，或者根本没有。组织架构的部分可以参考SRE的组织架构 | 樱桃沟夹事

组织文化

这个是大型企业和中小企业都一致的。我们需要将可靠性作为一个业务指标，使其能够在其他业务要求优先的情况下进行谈判和交易。而不是只把产品功能和收入，DAU作为唯一的指标。

SRE通过定量的方法，明确了运营可靠性与顾客满意度的关系。

通过优先考虑长期的、客观的成功度量标准，SRE促进了可靠性的持续谈判，其结果得到了更广泛的组织目标的支持。

前几天想要挪动一下自己的海外账户，之前是在民生香港开户的。下了app发现密码忘记了，那就找回密码吧，可找回密码需要蓝牙U盾确认，可我这个蓝牙U盾没有任何显示，我记得以前是有显示的，然后会让你来按的。

赶紧给95568打电话问下，结果人每天18点就下班了。那第二天再说吧。

第二天心想，旁边民生营业部也不远，于是就骑着电蹦子去了，结果这民生银行的柜员还没我了解的多，她们只会让你重新买个U盾，这不是已经买一个，怎么还要买啊，而且这个你看屏幕也亮，蓝牙也连着了，怎么就不行了呢。然后柜员还给客服打电话问问这个东西怎么验证，各种捣鼓了一下发现还是没有办法。不过说这个可以插PC上来登陆网银，那我自己回家试试吧。

回家登陆网银，现在直接要下载客户端了。客户端里民生香港要登陆账号还要账户号，还不能是用户别名。但是插着U盾发现了问题，居然这个U盾的证书过期了，这个中金金融认证中心有限公司颁发的证书有效期是5年的。于是再打95568问问怎么更新证书，客服一顿指导，发现我的证书过期时间太长了，无法按照他们标准的方式来更新了，得手机app联系远程客服，但是我说就是app登陆不上啊，人说你登陆国内的app.

于是登陆国内的app,联系远程客服，各种人脸，密码认证完了，总算把我要的证书标识名和证书授权码以短信形式发给我了。

按说这样就好了吧，我用这个标识名和授权码更新证书，结果一更新，提示我U盾序列号不。标识名发的是针对AABB的U盾，我手上的是CCDD的。妈的不是你们发错了吧。于是再打95568，问下这个U盾序列号的事情，人说可能大陆和香港的是2个U盾，然后又好心提醒我使用手机远程客服来获取香港U盾的标识名和授权书。

《技术为径》的第四章讲述了如何管理技术员工的。其中主要是4点，不过实际上作者写了10点。 其中我觉得最重要的就是建立良好的上下级关系，一对一跟团队成员沟通，授权和持续反馈这4个点。这个要是早点看，可能我在zy的时候不会那么的艰难。

与员工快速建立良好的上下级关系

1. 增进信任与默契度
   1. 和员工在可能出现问题的领域进行沟通。下面是作者列的详细问题，个人觉得作为初级管理者一定要多想想这些问题。
      • 应该如何表达对员工工作的认可？应该尽量公开表达还是尽量私下表达？
      • 如何反馈工作方面的意见和建议，最容易让对方接受？他是习惯于接受正式的，书面的表述还是习惯于口头反馈。
      • 员工工作的动力是什么？公司在哪个方面吸引了该员工？
      • 员工心情不好或者心烦的时候的具体表现？是否有一些高频事件引发其情绪低落，而我浑然不知？
      • 在职业生涯中，自己的下属是否有过上下级关系恶劣的糟心事？自己是否引以为戒，并尽量避免？
      • 员工是否有清晰的职业目标，自己如何可以帮助员工达到这些目标？
      • 员工入职之后是否有未解决的事务？
2. 制定一个“月/双月/季度”计划
   1. 新员工的资历越深，你就越应该推动他们自行建立这个工作计划，建立工作计划的过程，可以帮助员工将自己置于正确的学习轨道上。
3. 鼓励新员工通过更新入职文档的方式融入团队
4. 提前沟通自己的管理方式，说明自己对新员工的期待：不仅你需要了解新员工，新员工也需要了解你的风格和你对他的期望，这个是互相磨合的过程。
5. 从新员工处获取反馈：新员工会带来全新的视角和做事方法，从来暴露出一些团队现有成员很难意识到的问题。但是不能过分鼓励新员工批评现有流程或系统，这可能会导致团队的现有成员不满。

与团队成员沟通

1. 定期举行一对一会议：这个对于初级管理者来说还是很有必要的

2. 安排一对一会议：一般安排在周二到周四的上午开始忙碌之前。因为后面的时间要保持连续，容易被迫延后。

3. 调整一对一会议：

   1. 一个刚入职的新手同事需要继续保持会议，而资深的工程师就可以降低频次，但是如果对方做重大项目的时候需要帮忙解决一些问题。

   2. 如果该员工不擅长主动推送信息，那就需要保持继续面谈。

   3. 团队和公司的稳定程度如何？

一对一会议的不同风格

在《如何成为卓越的工程师》 一文中写了如何成为一个卓越的下属，那在《技术为径》里第二部分就是写如何成为优秀的小组长，最后是优秀的经理。

小组长在很多公司都缺乏一个完整的定义，很多时候都是由一些资深的工程师来兼任的，比如原先我司的纯业就是一个优秀的资深工程师。

个人感觉主要比一般工程师多以下两点能力，技术能力本身是比较高的，但不一定是最高的。

1. 沟通能力：组内沟通和外部沟通（如产品团队，销售和运营团队，以及管理层）
2. 项目管理能力：项目分解以及如何按时并保证质量的上线。

技术小组长除了推动项目跟好进展外，还应该利用自己的技术优势帮助整个团队提高效率。

书中列了优秀技术小组长的成长秘诀：取舍

上周球球在楼下玩了会之后居然给抱着一只纸箱子回家，一看里面有只小鸟，球球说这只小鸟受伤了，他也是别的小朋友给他的。

我心说这下得完蛋，这受伤的小鸟能活几天啊，这到时候死了又得哭的死去活来的。

球球拿回家后给小鸟换了一个窝还，给小鸟喂了水和小米，但是好像还不会自己吃，自己查了说是要喂奶，这赶紧给阻止了，没有听说小鸟要喝奶的。

第二天一查这个鸟是斑鸠，鸠占鹊巢的斑鸠。怪不得被其他麻雀从窝里给赶出来后掉地上了。这个斑鸠妈妈就是不怎么讲究啊，也不给自己吃饭。

下午球球居然把鸟连着盒子一起带出去了，给小朋友们看，小朋友们各种抱和抚摸。我也听到了小朋友说是斑鸠掉在了树下的水泥地上，所以才这么严重的。

晚上球球就把小鸟和盒子一起拿回家了。

《技术为径》是一本写给想成为管理者的工程师的书，其中第一章是说如何做好一个普通员工，其次2～4是章是说成为tech leader要做的事情。

技术领导者有主要以下风格，主要就是“放任自流”，“忽视型”，“微观型”等等。

作为一个下属希望自己的上级领导至少要做到以下内容，也就是所谓的管理基础。

管理基础

一对一会议

每周与自己的直属领导进行定期的一对一会议，是维持良好的工作关系的必要手段。一对一会议主要解决两个问题：

一直感觉云计算（cloud）这个词让大家比较晕。不过也不是我晕，当年robin，pony这些人不也没看懂的，记得robin当年还说过框计算这种，基本还是没明白。

现在这一代（互联网原住民）都把网络生活当作是自然的事情，刷小红书，刷B站，淘宝购物，美团外卖这些。

IDC

其实这些互联网服务都是依靠互联网数据中心（IDC）来提供服务的，你访问的文字，图片，视频，在线购物都是需要通过网络连接到IDC。在以前IDC是一个大家都并不了解的东西，记得当年去魔都武胜路机房这些都需要层层审批，非常的麻烦，要上个设备更是麻烦了，现在这些IDC每年两会期间都会禁止上新货者下设备。

这些IDC都会放在一些专业的建筑中，需要消防，电力，网络运营商，以及对于建筑物的抗震水平必须达到8级。当年天津港大爆炸的时候，有前同事当时就在附近的IDC中，IDC里的服务器和交换设备也都很正常，这里面是相当安全的，第二天企鹅派车把他们都接走了。

以前要出了不好的网络舆情，很多帽子叔叔还是会拔网线的。主要还是当时的封禁手段有限，IDC管理的大叔大妈只会拔电源这种方式。

在互联网行业，SRE的工作经常实际上看不出来，很多不懂的老板就觉得你们是多余的，这不系统一整年都好好的运行着，为啥还要这些人嗯？

SRE自夸文档

还有你非常需要一些材料来支持你的晋升和加薪。

所以我们需要自己写一份文档来列出自己的成就。

下面这个是Julia Evans和Karla Burnett在《SRE工程师应知应会97件事》里列出的对应文档的参考结构。

1. 今年的目标（你真的关注过安全吗？在团队中建立一种代码审查的文化）。

2. 明年的目标。

3. 项目（描述你的贡献及对公司的影响。通过数据表达是最好的方式）。

4. 指导和领导工作（包括社区建设和职业生态构建工作）。

5. 设计和记录（保留你写的设计文档和其他文档）。

6. 你学到了什么。

7. 工作之外（会谈！博文）。

第一代SRE是2016年以前Google内部的团队的，至于他们内部的组织架构是怎么样的，我们其实都不大清楚，Google也从来没有披露过，只是靠着《SRE》这本书推测是一个单独的团队。

第二代SRE就是很多大型互联网公司根据Google书中提示的，建立了一个独立的SRE团队，一般这个团队是归属于运维团队中的。

但是在实际的运行中，有一些问题是需要解决的。比如很重要的一点就是SRE需要去推一些稳定性的事情，需要跟产品和开发团队进行沟通，毕竟做了稳定性的事情后，那产品的功能迭代的事情就要减少。而且也未必很多开发团队愿意干这个事情。因为很多所谓稳定性的事情大部分都是重要但不紧急的。

这个时候需要SRE团队跟产品和开发团队进行沟通和排期。

这个时候如果公司内部各个团队沟通工作做的比较好的情况下，这些事情还是比较好推进的，比如我之前在X信的时候，因为从CTO到底层研发同学都非常关注可用性和成本，同时SRE和运维同学的水平又得到大家广泛认同，这个时候就是容易推进各项事宜的进展。这些可用性项目也是写入到CTO和各个研发负责人的OKR中的。

但是如果公司内部各个团队本来就是各自独立的，比如我在X右的时候，各个研发负责人各自维持一摊事情，就算是CEO来管也未必听。那你说这个事情应该怎么推进了。在强力推进了几个事情后，发现了这些问题，很多事情只能私下跟人好好聊聊，聊通了之后再名义上走一遍流程。但是后面发现在老板的OKR上也很少有这些事情。