zhouzhongping/wiki
1
0
Fork 0
Code

阅读：微信读书笔记

Browse Source
This commit is contained in:
周中平 2024-02-26 20:18:55 +08:00
parent 8370246ad5
commit f04806d0a1
Signed by: zhouzhongping
GPG Key ID: 6666822800008000
6 changed files with 1073 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Blog/2023 年终问答.md
View File

@ -29,7 +29,7 @@ Yes，一直在路上。
## 5.你去了哪些城市/州/国家？
云南、重庆、洛阳、安徽黄山、福建泉州、河南焦作、湖北张家界、浙江杭州、河南信阳、河南商丘。有机会想出国 ～
云南、重庆、洛阳、安徽黄山、福建泉州、河南焦作、湖北神农架、浙江杭州、河南信阳、河南商丘。有机会想出国 ～
## 6.明年你想要获得哪些你今年没有的东西？
@ -41,19 +41,19 @@ Yes，一直在路上。
## 8.你今年最大的成就是什么？
读书 50 +、更好的处理生活琐事。
读书 50 +、更好地处理生活琐事。
## 9.你今年最大的失败是什么？
没有好好的学习 XX ，丢人……
没有好好地学习 XX ，丢人……
## 10.你今年还遇到过哪些困难？
特别困难的事情到是没有，就是反反复复的因为呼吸道、感冒等影响身体状态。
特别困难的事情倒是没有，就是反反复复的因为呼吸道、感冒等影响身体状态。
## 11.你今年是否生过病或受过伤？
生病，特别是换季节各种甲流，感冒，头疼死了，还是要学会带口罩。
生病，特别是换季季节各种甲流，感冒，头疼死了，还是要学会带口罩。
## 12.你今年买过的最好的东西是什么？
@ -77,11 +77,11 @@ Yes，一直在路上。
## 17.哪首歌会永远让你想起这一年？
那首歌，凤凰传奇吧，今年听的巨多。
那首歌，凤凰传奇吧，今年听得巨多。
## 18.与去年的这个时候相比，你是：感到更快乐还是更悲伤了？变得更瘦还是更胖了？变得更富还是更穷了？
快乐与悲伤同在，同比快乐一些。稍微胖了一丢丢哈哈哈。目前一直穷的比较稳定。
快乐与悲伤同在，同比快乐一些。稍微胖了一丢丢哈哈哈。目前一直穷得比较稳定。
## 19.你希望自己能做得更多的是什么？
@ -177,7 +177,7 @@ Yes，一直在路上。
## 42.你是否有了新的住所或改变了居住环境？
没有新住所，但极大改善了生活居住环境。疫情几年，集体宿舍住的想吐……
没有新住所，但极大改善了生活居住环境。疫情几年，集体宿舍住得想吐……
## 43.你是否有新的心理健康或情绪管理技巧？

180
Book/个人成长/超级面试官：快速提升识人技能的面试实战手册.md Normal file
View File

@ -0,0 +1,180 @@
---
doc_type: weread-highlights-reviews
bookId: "31594809"
author: 仲平
cover: https://wfqqreader-1252317822.image.myqcloud.com/cover/809/31594809/t7_31594809.jpg
reviewCount: 3
noteCount: 64
readingStatus: 读完
progress: 99%
totalReadDay: 5
readingTime: 1小时56分钟
readingDate: 2023-07-07
finishedDate: 2024-01-15
title: 超级面试官：快速提升识人技能的面试实战手册
description: 面试是人才招聘过程中的重要一环，面试官的水平直接影响到所招人员的素质高低。 那么，面试官该具备哪些基本素质和技能呢？ 本书从面试环节出发，介绍了面试官定位、人才画像、面试准备、面试提问与追问、非语言信息观察、面试评分以及面试官的修养等与面试相关的内容。书中不仅穿插了大量的真实案例，便于读者快速理解和掌握知识点，而且在每一讲中都提供了对应的实操小工具，如人才画像分析表、面试提纲表和面试评语表等，帮助人力资源从业者快速掌握面试技巧，成为超级面试官。
keywords:
- 超级面试官：快速提升识人技能的面试实战手册
- 曾双喜
tags:
- 阅读/个人成长-人在职场
date: 2024-02-26
---
## 简介
- **书名**：《超级面试官：快速提升识人技能的面试实战手册》
- **作者**： 曾双喜
- **分类**： 个人成长-人在职场
- **ISBN**：9787115538253
- **出版社**：人民邮电出版社
## 概述
面试是人才招聘过程中的重要一环，面试官的水平直接影响到所招人员的素质高低。 那么，面试官该具备哪些基本素质和技能呢？ 本书从面试环节出发，介绍了面试官定位、人才画像、面试准备、面试提问与追问、非语言信息观察、面试评分以及面试官的修养等与面试相关的内容。书中不仅穿插了大量的真实案例，便于读者快速理解和掌握知识点，而且在每一讲中都提供了对应的实操小工具，如人才画像分析表、面试提纲表和面试评语表等，帮助人力资源从业者快速掌握面试技巧，成为超级面试官。
## 划线
> 面试官定位、人才画像、面试准备、面试提问与追问、非语言信息观察、面试评分以及面试官的修养
> 管理者最重要的事情就是招聘人才。
> 招聘就像谈恋爱一样，要找到一个合适的人是很难的。找错对象会很痛苦，招错人才的代价也很大。
> 如果招聘到不合适的人，公司就要付出相当于该员工15倍薪水的代价。
> （1）面试标准不清晰，不知道自己要招什么样的人；（2）提问无章法，想到什么就问什么；（3）仓促判断，只和应聘者交流了10多分钟就决定要不要这个人；（4）提出各种奇葩的问题，如询问星座、生肖等；（5）高高在上，提出各种问题刁难应聘者；（6）高谈阔论，说的比应聘者还多；（7）不知道怎样判断应聘者表述的真实性；（8）面试结束后，感觉应聘者挺好的，但是不知道具体好在哪里。
> 传统面试招到的多是面试能力强的人，并不一定是工作能力强的人，因此很多优秀人才与公司失之交臂。
> HR和业务经理在选人方面很难达成共识，对于HR推荐的候选人，业务部门认为他专业能力不行；而业务部门认可的候选人，HR又说他的价值观或动机不符合要求。
> 从技术层面来说，一次成功的招聘需要具备四个因素，分别是科学的评价标准、严谨的面试流程、科学的面试方法、专业的面试评委。
> 高管们年龄较大，学习创新能力下降，思维比较固化，对新鲜事物的接受度低，由于短时间内他们适应不了公司的氛围，也没做出什么业绩，所以只好离开公司。
> 董事长听了后略有所思，表示：“过去我面试了很多高管，总觉得面试时这些高管表现得光彩照人，招进来之后却发现他们的能力、个性、态度与面试时判若两人，其实最需要参加面试官培训的是我呀。”
> 美国心理学家麦克利兰提出的冰山理论，把人的素质划分为“冰山”以上的基准性素质和“冰山”以下的鉴别性素质，其中鉴别性素质包括内驱力、社会动机、个性品质、自我形象、态度等，它是区分绩效优异者与绩效平平者的关键因素。
> 谷歌公司认为，由优秀人才组成的员工团队，不仅能做出令人满意的成绩，还能引来更多的优秀人才，这就是所谓的“羊群效应”。
> 普通员工离职时，企业承担的直接成本是员工总收入的1.3倍，而管理人员离职，企业承担的直接成本则是其总收入的2.5倍。
> 滴滴出行创始人程维说：“我每天把30%的时间和精力用于面试，面试工作是第一优先级的……所有总监级以上的应聘者我都要见。”
> 雷军说：“如果你招不到人才，那是因为你投入的精力不够多。”
> 费罗迪曾表示：“大多数公司用2%的精力招聘，却用75%的精力弥补当初错误招聘造成的失误。”
> 他在面试的时候，只看重应聘者的学历、资历等，却不会辨别真伪，经常把一些会“忽悠”的人招进来，结果他们并不能创造好的业绩。
> 第四是面试效果评估认证。以复试通过率或试用期员工流失率等数据，对面试官的技能进行认证。
> “欣赏一个人，始于颜值，敬于才华，合于性格，久于善良，终于人品”。
> 阿里招聘新员工时，主要看他们是否诚信、是否能融入企业、能否接受企业的使命感和价值观，业务能力并不是最重要的。
> （2）岗位需要什么样的人？这是“硬”的条件，人力资源部门通过职位分析明确该岗位的任职者需要具备的学历、年龄、经验和技能等。
> 面试官知道自己需要什么样的人，也知道对方是什么样的人，但不知道在市场上有多少类似的人才，同类型人才的薪酬水平如何。所以面试官给出的条件并不能吸引他，或者与他的期望值不匹配。
> 不同发展阶段对人才的要求是不同的：从0到1，需要的是创业型人才，善于建立新的模式；从1到N，需要的是开拓型人才，善于建章立制；从N到N+，需要的是运营型人才，注重细节管理和规范化运营；从N+到N++，需要的是变革型人才，帮助企业打破原有边界进行转型升级。
> 第一是公司外部环境，包括产业链、竞争对手、目标客户、主要产品及服务、行业发展趋势等
> 第二是公司战略规划。每家企业都有自己的经营战略，不同的战略对人才的数量和质量要求不同：实施发展型战略的公司需要的是开拓型人才；实现稳定型战略、成本领先型战略的公司需要的是运营型人才；实施多元化战略的公司需要的是复合型人才；实施差异化战略的公司需要的是创新型人才。
> [插图]
> 你在面试的时候提问比较随性，就像聊天一样，想到哪儿问到哪儿，完全没有章法和逻辑，所以面试了半天也不知道如何评价应聘者，不确定到底能不能录用他。
> 第一类是不能问的问题，如政治、宗教信仰、商业机密，以及个人隐私的话题。2019年国家出台相关规定，企业面试时不得询问妇女婚育情况[插图]。面试官提出这类问题，不仅会引起应聘者的反感，还可能会导致面试的失败。
> 因此，面试官应当先充分了解应聘者，同时让应聘者对企业及岗位有一定程度的认识。然后，面试官要先询问应聘者目前或上一份工作的薪资，得到一个较合理的参考标准。
> 在面试过程中，面试官要尽量采用行为化问题、情景化问题或将两者结合起来进行提问
> 什么是行为面试？行为面试和情景面试有什么区别？行为面试和结构化面试有什么关系？电话面试、视频面试、无领导小组讨论算不算面试？
> 结构化面试也叫标准化面试，是指按统一制定的标准和要求进行的面试。
> 严格来说，结构化面试不是一种面试技术，而是一种面试形式。
> 一个人的行为模式是相对稳定的，不会在较短的时间内发生大的变化，特别是在遇到类似的情景时，人的行为反应倾向于重复过去的方式。
> 说到行为面试，就不得不说STAR原则，“STAR”是SITUATION（背景）、TASK（任务）、ACTION（行动）和RESULT（结果）四个英文单词的首字母组合（如图3-4所示）。在行为面试的过程中，面试官要按照“STAR”原则提问，也就是要求应聘者对每一个问题讲一个小故事，必须是自己经历的真实的故事，包括（1）发生的时间、地点、内容和涉及的人员；（2）要完成的任务或遇到的问题；（3）自己采取了哪些行动；（4）得出了什么样的结果，取得了什么样的成绩。这四部分内容缺一不可。所以，也有人把行为面试法叫作“STAR面试法”。
> 情景面试主要考察应聘者的思维灵活性与敏捷性、语言表达能力、沟通技能、处理冲突的能力、组织协调能力、人际关系处理能力等素质特征。
> 面试官通过提出生硬的、不礼貌的问题故意使应聘者感到不舒服，针对某一事项或问题做一连串的发问，直至应聘者无法回答。
> 。这一方法的特点是让应聘者回忆过去的经历，通俗地说就是让应聘者讲故事，讲完整的故事，讲真实的故事，讲自己的故事，讲已经发生的故事
> [插图]
> 培训界有一个“721法则”，即能力提升的70%来自工作实践中的锻炼，20%来自向有经验的人学习，10%来自培训课堂和书本的学习。所谓读万卷书不如行万里路，行万里路不如阅人无数，阅人无数不如高人指路，高人指路不如自己去悟。自己去悟，就是指在行动中感悟、领悟和觉悟，这是学习的最高境界。
> 为了使追问的问题更加细化，可将STAR原则细化为5W2H方法。What:发生了什么事情？面临的任务是什么？要解决的问题是什么？结果如何？造成了什么样的影响？When：什么时候发生的？什么时间开始？什么时候结束？多长时间一次？Where：在哪里发生的？Who：哪些人参与了？你的角色是什么？Why：为什么会发生这样的事？为什么要这么做？当时你是怎么想的？How：你是怎么做的？具体经过是怎样的？How many/much：花了多少钱？用了多长时间？追问越深入、越有针对性，面试官就越能获得应聘者真实、丰富的信息，同时追问也是一个复杂的、高难度的工作，面试官必须注意把握追问的时机和尺度，尽量使追问适时、适度。
> 以探询离职原因为例，面试官可以从应聘者的职务变动和升迁的轨迹、公司业务发展情况、对加班和出差等的承受程度、对上司领导风格和企业文化的偏好、对权力和地位的欲望、对物质和精神激励的侧重程度等多个角度，了解应聘者是由于对哪些方面不满意而离职的。常用的追问示例如下。
> [插图]
> 企业在招聘过程中，强调学历、名牌大学毕业、名企工作经历等便是陷入这种陷阱的体现。须知，即使在知名大公司中，也有三分之一的人不称职。
> 等级0（不合格）：等待别人吩咐才行动。等级1（合格）：向领导询问该做什么。等级2（良好）：提出建议，然后采取相应的行动。等级3（优秀）：自己主动行事，然后定期汇报。
> 等级0（不合格）：没有表现出相应的行为。等级1（合格）：大多数人都会采用的常规行为。等级2（良好）：根据存在的问题采取有针对性的行为。等级3（优秀）：有创新、超常规的行为。
> 这些负面事件往往隐藏了应聘者的价值观、求职动机和性格特征等因素，是面试官需要深入挖掘的，但是不能因为有失败经历就全面否定一个人，而应当重点关注应聘者是否能够从失败经历中汲取教训，在之后的工作中是否有明显改善。
> [插图]
> [插图]
> [插图]
> [插图]
> [插图]
> 面试是双向的了解过程，面试官和应聘者只是角色不同而已
> 早上好，我叫张××，是这家公司的人力资源部经理。到目前为止，我已经在这个岗位上工作8年了，面试过许多应聘者。在我的职业生涯中，我主持、参与了超过300场面试。希望今天我们能进行愉快的交流。
> 要成长为超级面试官，一方面要争取更多的面试机会，并及时总结面试经验；另一方面，平时要注意多观察人的行为表现，不断进行总结提炼。
> 会写文章的人至少具有以下两个强于一般人的优点。第一，善于用简明扼要的语言阐述深奥的问题。第二，看问题的深度、高度比一般人要强
> 凡是有小才华的人都是比较有潜力的人。这是因为，第一，才华能反映一个人的聪明程度，有小才华的人的学习能力、创新能力比一般人要强；第二，只有在一个领域持续地投入和付出才会有产出，才能表现出相应的才华，因此有小才华的人不仅勤奋，而且具备一定的专注度和坚韧性。
> 第一种是类比。当需要向一个外行人讲述一个很专业和深奥的内容时，有幽默感的人非常善于利用类比手法，通过一些生活中容易理解的案例来解释这些道理，让听众易于理解和接受。善用类比手法的人，通常总结归纳能力强，能够看穿问题的本质，在表达方面可以做到深入浅出。
> 从古至今，树上的苹果砸中了无数人的头，为什么只有牛顿发现了万有引力？因为他提出了一个核心问题：苹果为什么会落地？
> 人的成长在很大程度上是由周围优秀的人推动的。有一个研究显示，一个人的水平约等于与他交往最多的五个人的水平的平均值。
> [插图]
## 笔记
> 谈恋爱最大的烦恼是爱我的人我不爱、我爱的人不爱我，招聘面试最大的烦恼是我要的人不来、来的人不是我要的；谈恋爱与招聘面试都是双向选择，需要双方情投意合才能走到一起。
💭 互相选择，彼此成就
> 人类学家雷·博威斯特指出：在一次面对面的交流中，语言传递出的信息量在总信息量中所占的份额还不到35%，剩下超过65%的信息都是通过非语言交流方式传递出去的。
💭 肢体语言，行为举止
> 面试的目的是选出合适的人，而不是把应聘者难倒。
💭 没有人天生就是契合具体工作岗位，只需要方向一致，尽可能的合适就好。
## 书评
## 点评

151
Book/文学/凤凰项目：一个IT运维的传奇故事（修订版）.md
View File

@ -3,8 +3,8 @@ doc_type: weread-highlights-reviews
bookId: "27337404"
author: 仲平
cover: https://cdn.weread.qq.com/weread/cover/74/YueWen_27337404/t7_YueWen_27337404.jpg
reviewCount: 1
noteCount: 49
reviewCount: 2
noteCount: 117
title: 凤凰项目：一个IT运维的传奇故事（修订版）
description: 本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。
keywords:
@ -12,8 +12,13 @@ keywords:
- 吉恩·金 凯文·贝尔 乔治·斯帕福德
tags:
- 阅读/文学-散文杂著
date: 2023-12-10
---
date: <% tp.date.now("YYYY-MM-DD") %>
readingStatus: 读完
progress: 100%
totalReadDay: 16
readingTime: 6小时40分钟
readingDate: 2022-11-28
finishedDate: 2023-12-13
---
@ -128,6 +133,140 @@ date: 2023-12-10
> 你们应该创建亨伯尔和法利所说的‘部署管道’。那是从代码签入到投产的整个价值流。那不是一种技术，而是生产。你们应该对所有东西都进行版本控制。所有东西，不只是代码，而是创建环境所需的每一样东西。然后，你们应该把整个环境创建流程自动化。
> 令人惊讶的是，克里斯的反应最为激烈。“什么？我们究竟为什么要一天开展十个部署？我们的部署冲刺周期是三个星期。我们拿不出那么多东西来一天部署10次！”
> 返工和准备时间过长问题的另一个显著来源是代码打包流程，在此阶段，IT运维部对经过开发部检查的内容进行版本控制，然后生成部署包。尽管克里斯和他的团队尽可能地记录代码和配置，总还有东西会遗漏，这些东西只有在部署之后，代码无法在环境中运行时才会被发现
> “这看起来很有希望。如果能把环境标准化，并把这些环境投入开发部、QA和IT运维部的日常使用，我们就能消除大部分在部署流程中因差异而导致的悲剧。”
> 我对威廉和布伦特说：“好吧，伙计们，你们有魔法棒了。你们要身先士卒。告诉我，你们会怎样设计生产线，让工作永远不会往回走，让工作流快速高效地向前移动？”他们俩都一脸茫然地看着我，我有些恼火地说：“你们有一根魔法棒！用它啊！”“这根魔法棒有多强？”威廉问。我重复了之前对玛姬说的话：“这是一根非常强大的魔法棒。它能做任何事。”
> 从很多方面来看，开发人员简直就是我所青睐的性情的对立面。我喜欢创造并遵守流程的人，喜欢重视严谨与纪律的人。而这些人偏偏喜欢心血来潮、异想天开，跳开流程办事。
> “我们不需要任何新硬件。”这个开发人员回答，“我们投入了很多精力来建立我们能够部署的计算机图像。为什么不把它们发送到云上？在我们需要的时候，可以运转成百上千个计算实例，完成后再销毁它们，成本只是我们所用的计算时间。”
> 结果大放异彩！超过20%的受访者访问了我们的网站，超过6%的人购买了商品。这个转化率高得令人难以置信，可能比我们之前开展过的所有活动都要高出五倍。
> 玛姬很快同意了，但是开发人员仍然花了两个小时进行变更和部署。现在，可以通过一个配置设定来禁用这个功能，因此下一次我们就能在几分钟内弄好，而不需要一整套代码上线了。这才是IT运维友好型的研发设计嘛！在生产中管理代码变得越来越容易了。
> 独角兽团队简直棒极了。他们已经从每两周开展一次部署过渡到每周开展一次部署，而且我们正在尝试每天开展部署。由于批量规模缩小了很多，我们可以很快做出小型变更。我们正在随时开展A/B测试。简而言之，我们从未这样迅速地响应市场，而且我相信，我们一定会大有可为。”
> 从“库存型生产”转变为“订单型生产”
> 。根据“改善形”，这让我不会觉得自己完全无用武之地。让我尤为骄傲的是，整整一个月来，我的团队都达到了把15%的时间用于预防性基础架构项目的目标，并且体现出了成果。
> 我们需要建立起一种文化，强调勇于冒险以及从失败中汲取教训的价值观，并强调通过反复实践以致炉火纯青的必要性。
> 我不希望张贴宣传质量与安全的海报。我希望我们的改进能够体现在日常工作的所需所用上：应用到日常工作之中。
> “你帮助我认识到，IT不只是一个部门。相反，它就像电力一样无处不在。IT是一种技能，就像能读会算一样。
> 希望每一个雇员都多少掌握这些技能。理解技术能够做什么、不能做什么，已经成为这家公司里每个部门必须具备的一种核心竞争力。要是业务经理领导了一个不具备这种技能的团队或项目，他们就会失败。
> 要是你能做到，我就准备培养你。我想把你放上一个两年计划的快车道。你将在销售和市场营销部门轮岗，管理一家工厂，积累国际经验，维护关键供应商的客户关系，以及管理供应链。相信我，这可不像度假那么轻松。你需要帮助，很多很多帮助。埃瑞克很好心地答应会指导你，因为我们俩都相信，这将会是你做过的最困难的事。
> 每一个称职的COO都会是从IT部门出来的。任何尚未精通IT系统就负责管理公司运行的COO，都只会是金玉其外的傀儡，需要依靠别人来开展工作。
> 史蒂夫就像是知道我在想什么一样，他说：“在好几个月之前，埃瑞克和我第一次见面的时候，他说IT部门和业务部门之间的关系就像是一场不协调的婚姻，双方都感到无能为力，并且被对方所挟持。我对此思考了好几个月，终于想清楚了一些事。”
> 所谓一场不协调的婚姻，是假定业务部门和IT部门是两个分离的实体。IT要么融入到公司的日常运行之中，要么融入到公司的业务内容之中。瞧！就是这样。没有矛盾，没有婚姻，也许连IT部门也没有
> 时的救世主固然好，但普世的圣经则更有用’。”
> DevOps的很多做法都是反直觉的，与常规认知相悖，甚至有争议。
> 鲁兹先生分析了布伦特的两面性：独食者和分享者。他写道：“我也碰到过一些非常聪明的人，他们秉持这种错误理念，即只有他们自己知道解决方案，才能永葆职位。这些人就是知识独食者。这个观念不对。没有人无可替代，无论这人有多优秀。当然可能特殊情况下解决问题需要的时间更长些，但缺了谁地球都能转。”
> DevOps原则和模式就是通过整合企业文化、企业架构和技术实践，让下降式螺旋变成上升式螺旋。
> 以前的经济环境里，商业通过移动原子创造价值，如今则通过移动比特创造价值。
> 正如爱德华·戴明博士的名句所言：“没人会强迫你学习……学习也并非生存必需。”技术的美好年代在等着我们，而非已经走远。进入技术领域永远都不晚，成为终身学习者也永远都不晚。
> 任何一个领域或学科想要取得进步和成熟，就需要认真反思它的起源，在反思中寻求不同的观点，并把这些不同观点的来龙去脉思考清楚，这对预见未来发展是非常有帮助的。
> DevOps实践可以与ITIL流程兼容。然而，为了支持DevOps所追求的更短的发布周期和更频繁的部署，ITIL流程的许多方面需要完全自动化，以解决配置和发布管理流程相关的许多问题，例如保持配置管理数据库和最终软件库是最新的。由于DevOps需要在服务事件发生时进行快速的定位和恢复，因此这些其实还是和ITIL的服务设计、事件和问题管理方面的原则相一致。
> 在这个竞争优势需要被快速验证和持续实验的时代，那些还不能应用DevOps实践的公司注定会在市场上败给敏捷的竞争对手，并可能会倒闭，和当年那些没有采取精益原则和实践的制造厂的后果类似。
> 大多数公司都不能在几分钟或几小时内完成变更需要的所有部署，往往需要几周甚至几个月的时间。他们更不可能每天在生产环境中做到成百上千次的部署，而是在以月甚至以季度为单位进行部署。对他们而言，生产环境的部署并不是日常工作，因此服务中断和各种事故总是与部署如影随形，“填坑侠”们总是前赴后继。
> 技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息。
> 第一部曲开始于IT运维，我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。
> 这样的背景下，我们进入了第三部曲，也就是最后一部曲。在这里，所有事情都变得更加困难，所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。我们的工作耦合得更加紧密，即使是很小的行动也会导致较大的事故，我们更加害怕和拒绝做出变更。工作需要更多的沟通、协调和审批；团队必须等待更长的时间，等待相关的工作完成；我们的工作质量持续恶化。车轮开始嘎嘎作响地缓慢移动，要想使之继续转动，就需要付出
> 许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚、失败或危及生存而不敢做正确的事。这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。
> 想要让新功能生效，我们只需要改变一个功能开关或者配置项即可，而不再需要经历数天或者数周的辛苦工作。这个小变更使新功能对更大规模的客户群可见，一旦出现错误，就会自动地回滚。因此，发布新功能变得可控、可预测、可逆，且压力也小了。
> 。我们的团队文化体现了高度的信任与合作，而不是指责
> 人们会因为冒险而获得回报。他们可以无所畏惧地讨论问题，而不是把问题隐藏起来或者往后拖延。毕竟，我们只有先认识到了问题，才能解决问题。
> 而且，因为所有人都需要对自己的工作质量负完全的责任，所以每个人在日常的工作中都创建自动化测试，并且使用同行评审的方式来保证在问题影响到客户之前就解决它。与从管理层向下授权审批的方式相反，上述过程降低了风险，让我们能快速、可靠、安全地交付价值，甚至可以在挑剔的评审人员面前证明我们拥有一个高效的内部控制系统。
> 因为注重质量，所以我们甚至会故意在生产环境中注入故障，从而了解系统是怎样以预期方式发生故障的。
> ❏ 吞吐量指标；❏ 代码和变更部署次数（频繁30倍）；❏ 代码和变更部署前置时间（快200倍）；❏ 可靠性指标；❏ 生产环境部署（变更成功率高60倍）；❏ 平均服务恢复时间（快168倍）；❏ 组织性能指标；❏ 生产力、市场份额以及营业目标（大约2倍以上）；❏ 市值增长（3年内高出50%）。
> 当我们增加开发人员的数量时，由于沟通、集成以及测试开销，单个开发人员的生产力通常会显著下降。弗雷德里克·布鲁克斯在其著名的《人月神话》一书中强调过这一点。他解释说，当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。
> “三步工作法”的原则：流动、反馈和持续学习与实验。
> DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。
> 在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。
> 因为前置时间是客户能够体验到的时间，所以我们把重点放在缩短前置时间而不是处理时间上。不过，处理时间与前置时间的比率是十分重要的效率指标，为了实现快速的流动并缩短前置时间，必须缩短工作在队列中的等待时间。
> 但是技术工作者很容易被打断，因为对所有人而言，这个中断的后果似乎是不可见的，即便它对生产效率的影响比制造业更甚。例如，将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本。
> 通过限制在制品数，还能更容易地发现工作中的阻碍。[插图]例如，当限制在制品时，可能会发现居然没什么工作可干的，因为要等待其他人。虽然进行一项新工作（即“干点什么总比什么都不干强”）可能很诱人，但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，造成了很多优先级冲突问题。
> 一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证。这些工作可能还需要使用不同的工单系统或项目管理系统，编写技术规范文档，用会议、电子邮件或电话的形式进行沟通，可能还涉及文件共享服务器、FTP服务器和Wiki页面的使用。
> 例如，在瀑布型软件项目中，代码的开发可能花上一整年，在开始测试之前（甚至在向客户发布软件前），我们得不到任何质量反馈。在反馈稀少且滞后的情况下，工作结果是很难达到预期的。相反，我们的目标应该是在技术价值流的每个阶段（包括产品管理、开发、QA、信息安全和运维），在所有工作执行的过程中，建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更。
> 斯皮尔博士认为，群策群力的目的是遏制住问题，防止蔓延，然后定位和处理问题，避免复发。他说：“这样做可以让所有参与者都得到更深入的知识，理解如何管理系统，把无法规避的、早期的无知阶段变成学习的过程。
> 这就是休哈特提出的循环（即PDCA环）——计划（Plan）、实施（Do）、检查（Check）、改进（Act），后来由爱德华兹·戴明推广并得到了迅猛发展”。
> 触发了安灯绳时，我们就聚集在一起解决问题，停止开展任何新工作，直到问题解决。[插图]这给价值流中的每个人提供了快速反馈（特别是那个导致系统故障的人），让我们能够快速地隔离和定位问题，避免出现更复杂的状况，导致问题的因果关系变得模糊。
> 尽可能多用自动化方式执行通常由QA和信息安全人员来进行的质量检查
> 要在问题发生时识别问题，群策群力解决问题并构建新的知识，在源头控制质量，并且不断地为下游工作中心做优化。
> 第一步建立了从左到右的工作流，第二步建立了从右到左的快速、持续的反馈，第三步要建立持续学习与实验的文化。
> 工人犯了错就会受到惩罚，那些提出建议或指出问题的工人则会被认为是告密者或管闲事的人。当发生了上述情况时，领导层会故意压制，甚至进行惩罚，这导致了质量和安全问题的进一步恶化
> 4.3 把局部发现转化为全局优化
> 一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益
> 这样带来的结果是：在任何一组新船员出海时，他们都能迅速地从集体长期积累的智慧中获得成长。
> 在技术价值流中，我们也应该通过类似的机制建立全局知识库。例如，把所有事故报告转化成可搜索的知识库，让有需要的团队能更加方便地使用它去解决类似问题，同时建立起组织级的共享源代码库，让所有人可以方便地使用整个组织的代码、库和配置。这些机制有助于把个人的专业知识转化为服务更多成员的集体智慧。
> 另外，还可以通过演习的方式来预演大规模故障，比如关闭某个数据中心。或者在生产环境中注入大规模故障（如Netflix著名的“捣乱猴”，它会随机杀死生产环境中的进程和服务器），来验证系统的可靠性是否达到了预期。
> 领导者通过“做出所有正确的决定”来领导团队。
> 领导者可以使用下列问题来帮助和辅导实验者。❏ 上一步做了什么？发生了什么？❏ 你从中学到了什么？❏ 现状如何？❏ 下一个目标条件是什么？❏ 当前工作有什么阻碍？❏ 下一步做什么？❏ 期望的结果是什么？❏ 什么时候能进行复查？
> 三步工作法的第三步原则实现了学习型组织，实现了职能部门之间的高度信任和跨部门合作，接受了“复杂系统中总会发生故障”的事实，并鼓励谈论任何问题以建立一个安全的工作系统。它还要求将日常工作的改进制度化，把局部成果转化为可供整个组织全局使用和学习的知识，以及不断向日常工作中注入张力
> 参与者所面临的游戏复杂性和工作量会逐轮递增。每一轮游戏结束后，教练都将帮助参与者“回顾”（上一轮发生了什么，参与者做了什么，参与者从中学到了什么）“思考”（哪些可以做得更好或者采用其他方式）以及“决策”（下一轮游戏应该如何做）。只有这样，参与者才能够学习到如何持续不断地提升他们的业绩和工作能力，从而在面对更复杂的工作环境和更大工作量的情况下仍然能够游刃有余。
> 产品负责人不应该只关注具有创新性的产品和功能，还需重视维护工作和移除技术债务等优先级。
> 我从八年前就开始尝试用沙盘去进行培训教学，在教学过程中，我最大的感触是：用沙盘教学能给学员带来无以伦比的感受，这种感受很可能会颠覆学员顽固的思维、接受我们的理念。
> 国际最佳实践管理联盟源于欧洲，是由欧洲最佳实践联学会携手国际知名出版机构、资格认证机构、咨询机构和行业专家共同发起的一家推广国际最佳实践管理体系和框架标准的非营利性组织
## 笔记
@ -135,6 +274,10 @@ date: 2023-12-10
💭 任何事物都必须存在生命周期
> DevOps是把精益原则应用到技术价值流中的结果，并探讨DevOps的三步工作法：流动、反馈以及持续学习与实验。
💭 正反馈
## 书评

82
Book/经济理财/人力资源管理从入门到精通.md Normal file
View File

@ -0,0 +1,82 @@
---
doc_type: weread-highlights-reviews
bookId: "23911060"
author: 仲平
cover: https://wfqqreader-1252317822.image.myqcloud.com/cover/60/23911060/t7_23911060.jpg
reviewCount: 0
noteCount: 18
readingStatus: 读完
progress: 100%
totalReadDay: 2
readingTime: 1小时20分钟
readingDate: 2023-07-05
finishedDate: 2024-02-18
title: 人力资源管理从入门到精通
description: 本书是一本企业人力资源管理实务书，由浅入深地介绍了人力资源管理的具体内容，即：在企业中，人力资源部门员工具体做什么、怎么做。职位不同，所需具备的知识和能力也是不同的，纵向职位层级的划分，构成了本书的框架：入门篇——人力资源专员的应知应会，提升篇——人力资源主管的工作技巧，精通篇——人力资源部经理的管理技术。全书共20章。从HR入行须知讲起，入门篇介绍了一个基本不懂业务的新手如何快速成长为熟手；提升篇介绍了人力资源主管的工作技巧，在专员、主管的层级，按五大模块（人事、招聘、培训、薪资、考核）具体介绍；精通篇，介绍了人力资源部经理的管理技术，包括组织架构、人力资源预算、体系审核、猎头合作、人力资源软件选型、人力资源规划、经营计划与预算。本书是作者12年企业HR从业经历的全面总结，适合企业人力资源部专员、主管、副经理、部门经理、总监等阅读，也可供本科生、研究生等作为参考书。
keywords:
- 人力资源管理从入门到精通
- 张明辉
tags:
- 阅读/经济理财-管理
date: 2024-02-26
---
## 简介
- **书名**：《人力资源管理从入门到精通》
- **作者**： 张明辉
- **分类**： 经济理财-管理
- **ISBN**：9787302392002
- **出版社**：清华大学出版社
## 概述
本书是一本企业人力资源管理实务书，由浅入深地介绍了人力资源管理的具体内容，即：在企业中，人力资源部门员工具体做什么、怎么做。职位不同，所需具备的知识和能力也是不同的，纵向职位层级的划分，构成了本书的框架：入门篇——人力资源专员的应知应会，提升篇——人力资源主管的工作技巧，精通篇——人力资源部经理的管理技术。全书共20章。从HR入行须知讲起，入门篇介绍了一个基本不懂业务的新手如何快速成长为熟手；提升篇介绍了人力资源主管的工作技巧，在专员、主管的层级，按五大模块（人事、招聘、培训、薪资、考核）具体介绍；精通篇，介绍了人力资源部经理的管理技术，包括组织架构、人力资源预算、体系审核、猎头合作、人力资源软件选型、人力资源规划、经营计划与预算。本书是作者12年企业HR从业经历的全面总结，适合企业人力资源部专员、主管、副经理、部门经理、总监等阅读，也可供本科生、研究生等作为参考书。
## 划线
> 在企业中，人力资源管理具体做什么、怎么做。这个问题，很容易被模块化为人事、招聘、培训、薪资、考核五大模块，以及岗位、HR规划两大基础。
> HR：人力资源，人力资源部，人力资源专业人员。HRM：人力资源管理，人力资源部经理。HRD：人力资源开发，人力资源总监。HRVP：人力资源副总裁。HRBP：人力资源业务合作伙伴，派驻到各业务部门的HR。HR Unit：人资单位，人力资源部门。
> 新员工报到入职当天，先由人力资源部按照正常流程办理入职手续。可能包括：提交核对身份证、相关证件，签订劳动合同，领取门禁卡（饭卡）、员工牌，开通公司邮箱、办公系统OA账号，办理工资卡，发放员工手册、电脑、必要的办公用品等。可通过邮箱发放通讯录，请新员工去OA下载并自学公司规章制度、财务报销流程等，还可以直接把职位说明书发给他。然后，人力资源部经理（或直接主管）找新员工谈话。除了表示欢迎，还要交代他尽快熟悉情况，包括公司、本部门、本岗位的情况。
> 第一种意思，熟悉办公环境。
> 第二种意思，熟悉人头。
> 第三种意思，熟悉公司规章制度。
> 第四种意思，熟悉工作情况。
> 总之，HR新手的工作，可以概括为：办事，跑腿，打电话，录数据，做表单。
> 每做一件事情之前，都要想一想：依据（法规政策，公司内部规章制度）是什么，需要准备哪些材料、是否齐全，相关领导、岗位人员是否签字确认（投入）；
> 所以，直接主管在布置任务时，要把意图讲解、交代清楚，并向其确认：我刚才提到的事情、任务，你再重复下，有没有问题？新手也要在领任务时，多问一句：领导（主管），您刚才交代的任务，我理解是这样的，对吗？这就可以在源头上避免方向上的偏差。
> 甚至，在晚上或周末时，也可以做些额外的工作。现在的工作节奏快，新手没有在额外时间投入准备，在8小时内把事情做完，有时是不现实的；而经过阶段性的工作历练，在工作中学习，熟手是可以在8小时内把工作基本做完的。
> 一个成功的人需要四种人来帮助他：高人指点、贵人相助、爱人激励、小人监督
> [插图]
> （1）假设你所在的部门下设6个科，你是某科的科员，在你们科里，除了科长之外，大家公认你的业务能力最强。有一天，部门经理交给你一份刚收到的会议通知，让你去参加某个会议。请你谈谈，从你接到通知那一刻到参加会议前，你会做些什么？（2）如果你入选了，但你的岗位级别定得较低，而你的主管在学历、资历、能力等方面都不如你，你该怎么办？（3）请你说说与领导相处和与同事相处的不同点。（4）你和你的上司有过意见不一致的情况吗？如果有，且你觉得自己理由充分，你会据理力争吗？如果不会，为什么？你是否担心今后他给你“穿小鞋”？（5）企业管理人员的选择可以采用外部招聘和内部提升两种方式，你认为各有何优缺点？（6）面对客户除工作之外的要求，如暗示要财务旅游、招待，你如何对待？（7）你管理的员工及时处理了工作中发生的紧急情况，但违反了规章制度，事后，你会怎么办？（8）请你为我们这次面试做个小结或提个建议好吗？你对我们几个面试人员有什么看法和建议？（9）原单位的领导对你的离开会持什么态度？会不会挽留你？（10）请用三个词评价你自己（考虑半分钟）
> （1）请谈谈你现在的工作情况和工作业绩。或在你最近的工作中，最突出的业绩是什么？（2）你认为现在的工作对你的发展有何影响？你为什么想换工作？对于这个岗位你有哪些优势和不足？你打算怎样弥补不足？（3）你怎样理解你所应聘的岗位？你觉得如果我们录用你，你能为我们带来的最直接的效益是什么？（4）你需要多长时间来适应一个新工作岗位？最难处理的是什么事情？为什么？（5）你最富有创造性的工作成果是什么？（6）对你而言，“成功”有何含义？在你以前的工作经历中，什么事令你最有成就感？（7）最不喜欢怎样的工作？觉得自己最大的失败是什么？从中吸取了哪些教训？
> （1）你为什么应聘我们公司？你对我们公司有哪些了解？你最看好公司哪些方面？（2）你向往怎样的工作环境？欣赏怎样的领导风格？最反感怎样的领导风格？（3）你觉得至今为止，什么事情或什么人对你的影响最大？如何影响你？为什么？（4）你平时最喜欢什么休闲活动？最喜欢哪部文学作品或者哪个人物，为什么？（5）请结合自己的情况，谈谈你对公司晋升制度的建议？（6）你是如何看待事业和家庭之间的关系的？平时周末做什么？如经常需要周末加班，会有什么问题？为什么？（7）在你看来，当今最优秀的或最成功的企业是哪一家？为什么？（请考虑一分钟）（8）你选择工作时，薪酬的重要性排在第几位？排在第一位的是什么？为什么？
> 第一章：总则。介绍部门职能说明书的使用、岗位职责说明书的使用、名称定义。第二章：公司组织结构图。第三章：部门职能说明书。包括13个部门。第四章：岗位结构。包括董事会机构岗位结构图、集团职能部门岗位结构图。第五章：岗位职责说明书。包括63个岗位。
> （1）A猎头公司的寻访流程，包括6个阶段：需求分析、企业了解、综合分析、寻访猎取、人才推荐、跟踪服务，具体见表17.1。表17.1 猎头寻访流程[插图]
## 笔记
## 书评
## 点评

177
Book/计算机/SRE：Google运维解密.md Normal file
View File

@ -0,0 +1,177 @@
---
doc_type: weread-highlights-reviews
bookId: "26271721"
author: 仲平
cover: https://wfqqreader-1252317822.image.myqcloud.com/cover/721/26271721/t7_26271721.jpg
reviewCount: 7
noteCount: 57
readingStatus: 在读
progress: 18%
totalReadDay: 5
readingTime: 1小时29分钟
readingDate: 2023-04-09
title: SRE：Google运维解密
description: 在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。本书适合各种水平的运维工程师参考使用。
keywords:
- SRE：Google运维解密
- 贝特西·拜尔等
tags:
- 阅读/计算机-计算机综合
date: 2024-02-26
---
## 简介
- **书名**：《SRE：Google运维解密》
- **作者**： 贝特西·拜尔等
- **分类**： 计算机-计算机综合
- **ISBN**：9787121297267
- **出版社**：电子工业出版社
## 概述
在本书中，不仅展示了 Google 是如何运用各种计算机工具软件、硬件以持续部署和监控一些世界上最大的软件系统的。还展示了在运维过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。本书适合各种水平的运维工程师参考使用。
## 划线
> 大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。
> SRE就是运行和管理这百万台服务器和众多分布式系统的关键。
> SRE强调的是对问题和故障的自动处理，而非人工干预；再者，按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己开发的程序更熟悉，易于处理程序上线过程中遇到的问题。
> 100%的可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，所以Google会针对每种产品设定一个错误预算（容错率），既能保证用户体验又不影响创新和部署的速度。
> SRE是一群天生的怀疑论者，我们怀疑一切宣传起来“高大上”的技术，以及任何“神奇”的产品——我们只想看具体的设计架构、实现细节，以及真实的监控图表。
> SRE其实是一群崇尚工匠主义的人，我们坚信只要不断地解决根源问题，服务质量就一定会得到提升。而SRE正是用这种“日拱一卒”的方法造就了Google这个世界级的奇迹。
> 本书体系化地覆盖了运维工作的方方面面，是一本运维行业的教科书。
> 更重要的是，我们展示了在建设过程中，Google 工程师团队是如何学习、成长、反复修改，最后定义出一套完整的工具和科技体系的过程。IT 行业大多自我封闭，交流过少，很多从业人员都或多或少地受教条主义的限制。如果Google 工程师团队能克服这个惯性，保持开放的精神，那么我们也能够一起和他们面对 IT 行业内最尖端的挑战。
> 今天，我们能感受到整个行业都在鼓吹厚颜无耻的 “代码拿来主义”（just show me the code）。开源软件社区内部正在形成一种“不要问我问题”的风气，过于强调平等却忽略领域专家的意见。Google 是行业内为数不多的，愿意投入精英力量钻研本质问题的公司，而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件，用来链接日益庞杂的软件、人和海量的数据。
> 一个公司的成长，意味着整个公司商业模式和工作模式的扩展，而不是简单的资源扩张
> 有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]
> 从这个视角出发，我们认为如果软件工程职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统的生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。
> 有的时候，SRE 和产品研发团队共同工作，其他时候我们需要开发这些系统的额外组件：例如备份系统和负载均衡系统等。理想情况下，同时推进这些组件在多个项目中复用。还有的时候，我们的任务是想出各种各样的办法用现有组件解决新的问题。
> 这与盖房子有些类似，如果一开始将整个地基打好并保持继续修缮，要比盖好房子之后再重新修改设计要容易得多
> 团队文化就是从一切经历中不断学习，包括来自那些我们最意想不到的地方的经历。
> 只有靠着对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。这就是SRE 最重要的理念！欢迎加入SRE的大家庭！
> 不能将碰运气当成战略。
> 极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”
> 由于两个部门使用的语境不同，对风险的定义也不一致。
> 开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。
> 目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
> 所有的SRE团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。
> （a）对重复性、手工性的操作有天然的排斥感。（b）有足够的技术能力快速开发出软件系统以替代手工操作。
> SRE团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上
> 我们可以认为DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。同时，SRE是DevOps模型在Google的具体实践，带有一些特别的扩展。
> “错误预算”起源于这样一个理念：任何产品都不是，也不应该做到100% 可靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。一般来说，任何软件系统都不应该一味地追求100% 可靠。因为对最终用户来说，99.999% 和 100% 的可用性是没有实质区别的（详见附录A）
> 一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
> 但是长久看来一个手持“运维宝典”经过多次演习的on-call工程师才是正确之路
> 由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的办法”而生
> Google的大部分计算资源都存放在自主设计的数据中心中。这些数据中心拥有自己设计的供电系统、制冷系统、网络系统以及计算机硬件（参见文献[Bar13]）。
> 一个典型的Google数据中心的拓扑结构：● 约10台物理服务器组成了一个机柜（Rack）● 数台机柜组成一个机柜排（Row）● 一排或多排机柜组成了一个集群（Cluster）● 一般来说，一个数据中心（Datacenter）包含多个集群● 多个相邻的数据中心组成了一个园区（Campus）
> 因为一个集群中包括很多硬件设备，每天硬件设备的损坏量很高。在一年内，一个单独集群中平均会发生几千起物理服务器损坏事件，会损失几千块硬盘。
> 如果一个工程师遇到了他工作的项目之外的一个基础组件的问题，他可以直接修改这个问题，向管理者提交一份改动申请（changelist,CL），等待代码评审，最后直接提交。
> 任何对自己项目代码的改动也需要代码评审。
> 有些项目组甚至在实践自动部署机制：提交一个新版本，测试通过后，将直接部署于生产环境。
> 监控系统都是运维生产环境必不可少的组件。如果没有针对服务的监控，就无从得知目前服务的状态，如果不知道服务的状态，就无从谈起维护服务的可靠性。
> 极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。
> 尽管当时YouTube已经有了一个很出色的产品，但它仍然在不断变化和快速发展着。因此，我们为YouTube设定了一个相比我们企业的产品更低的可用性目标，因为快速发展更加重要。
> 一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。
> 对意外事件的容忍程度有多高？做得太少，我们就只能设计出一个脆弱无用的产品。做得太多，我们的产品可能没有人会使用（但运行非常稳定
> SLI是指服务质量指标（indicator）—该服务的某项服务质量的一个具体量化指标。
> 如果系统正常运转中需要人工干预，应该将此视为一种Bug。
> SRE的一个公开目标是保持每个SRE的工作时间中运维工作（即琐事）的比例低于50%。SRE至少花50%的时间在工程项目上，以减少未来的琐事或增加服务功能。
> 让我们多创新，少干琐事吧！
> 监控系统应该解决两个问题：什么东西出故障了，以及为什么出故障。
> “现象”和“原因”的区分是构建信噪比高的监控系统时最重要的概念。
> 监控系统的4个黄金指标分别是延迟、流量、错误和饱和度（saturation）。
> ● 每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。● 每个紧急警报都应该是可以具体操作的。● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。
> -mail警报的价值通常极为有限，很容易变成噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况。
> 一致性地执行范围明确、步骤已知的程序—是自动化的首要价值。
> 在行业内普遍认同的是，在产品生命周期中一个问题越晚被发现，修复代价越高；
> 自动化是“元软件”，也就是操作其他软件的软件。
## 笔记
> 系统运维长久以来都依赖实践积累之上的口口相传，经验通常是领域从业者手里掌握的秘诀。
💭 人肉运维哈哈哈
> 我们无法按照传统方式运维Google系统，必须要思考一种新的模式，但是同时我们也没有时间等待其他人验证和支持我们的理论。
💭 适合自己的才是最好的
> 有统计显示，一个软件系统的40%～90% 的花销其实是花在开发建设完成之后不断维护过程中的。[1]
💭 就像生孩子一样，十月怀胎一朝分娩，一辈子成人。
> 从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
💭 yaml 工程师哈哈哈
> 从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些SRE倾向于通过设计、构建自动化工具来取代人工操作。
💭 标准化，流程化，自动化
> 如果100% 不是一个正确的可靠性目标，那么多少才是呢？这其实并不是一个技术问题，而是一个产品问题。
💭 技术服务于客户
> 到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。
💭 人肉运维哈哈哈
## 书评
## 点评

478
Book/计算机/程序员的README.md Normal file
View File

@ -0,0 +1,478 @@
---
doc_type: weread-highlights-reviews
bookId: "3300065840"
author: 仲平
cover: https://cdn.weread.qq.com/weread/cover/31/cpplatform_ga4rqqfcxsqrnz84jtogyn/t7_cpplatform_ga4rqqfcxsqrnz84jtogyn1690877075.jpg
reviewCount: 35
noteCount: 176
readingStatus: 读完
progress: 99%
totalReadDay: 8
readingTime: 3小时44分钟
readingDate: 2023-09-07
finishedDate: 2024-01-10
title: 程序员的README
description: 对于刚刚成为软件工程师的新手来说，知道如何编写代码只是成功了一半。你可能很快就会发现，学校并没有教授在现实世界中至关重要的技能和工作中必要的流程。本书恰恰填补了这一环节，它是作者十多年来在大型公司指导初级工程师工作的教程，涵盖软件工程的基础知识和best实践。 本书第1～2 章讲解当你在公司开启你的职业生涯时会发生什么；第3～11 章会扩展你的工作技能，教你如何使用现有代码库、解决和防止技术债、编写生产级软件、管理依赖关系、有效地测试、评审代码、交付软件、处理On-Call 时的事故和构建可演进的架构等；剩余章节涵盖管理能力和职业阶梯的提升等相关内容，例如敏捷计划、与管理者合作以及成长为资深工程师的必经之路。本书中非常重要的一部分内容是教你如何应对糟糕的管理，以及如何调整自己的节奏。 本书内容不仅浅显易懂，还覆盖整个软件开发周期，是一本技术主管希望每名新入行的工程师在开始工作之前都能阅读的书。
keywords:
- 程序员的README
- 克里斯·里科米尼 德米特里·里亚博伊
tags:
- 阅读/计算机-计算机综合
date: 2024-02-26
---
## 简介
- **书名**：《程序员的README》
- **作者**： 克里斯·里科米尼 德米特里·里亚博伊
- **分类**： 计算机-计算机综合
- **ISBN**：9787115599438
- **出版社**：人民邮电出版社有限公司
## 概述
对于刚刚成为软件工程师的新手来说，知道如何编写代码只是成功了一半。你可能很快就会发现，学校并没有教授在现实世界中至关重要的技能和工作中必要的流程。本书恰恰填补了这一环节，它是作者十多年来在大型公司指导初级工程师工作的教程，涵盖软件工程的基础知识和best实践。 本书第1～2 章讲解当你在公司开启你的职业生涯时会发生什么；第3～11 章会扩展你的工作技能，教你如何使用现有代码库、解决和防止技术债、编写生产级软件、管理依赖关系、有效地测试、评审代码、交付软件、处理On-Call 时的事故和构建可演进的架构等；剩余章节涵盖管理能力和职业阶梯的提升等相关内容，例如敏捷计划、与管理者合作以及成长为资深工程师的必经之路。本书中非常重要的一部分内容是教你如何应对糟糕的管理，以及如何调整自己的节奏。 本书内容不仅浅显易懂，还覆盖整个软件开发周期，是一本技术主管希望每名新入行的工程师在开始工作之前都能阅读的书。
## 划线
> 本书中非常重要的一部分内容是教你如何应对糟糕的管理，以及如何调整自己的节奏。
> 还覆盖整个软件开发周期，是一本技术主管希望每名新入行的工程师在开始工作之前都能阅读的书。
> 一名成熟的软件开发者的标志是打破固有的习惯，批判性地回顾旧代码，发现瑕疵，做到自省，且为没多做些什么而感到羞愧。
> 在本书的前几章中，“提问”就被高度重视，这让我感到非常高兴。向同事提问和学习是快速成长和习得新技能的有效方式。为你的工作成果感到自豪通常是件好事，但当自己在持续改进和交付中比以前做得更好时，你应该优先感到自豪。
> 软件开发本身带来的欣喜是一种“尤里卡时刻”的幸福体验，尤其是在无数个面对调试器“狂按”F10键的夜晚，自己提交的特性成功上线时的喜悦，抑或是眼看着自己设计的技术架构方案从纸面上的框图到代码实现再到最终交付的满足感。
> 在实际的工作中，成功地交付软件并不是只有唯一的路径可走。如何衡量与之匹配的需求、成本和风险才是考验团队的地方。
> 翻译完本书的最后一章时，正好是我踏入软件行业的12年整，此时的我却觉得自己的职业生涯好像才刚刚开始。
> 知道如何编写代码——也就是如何使用计算机去解决问题，仅仅是“战斗的一半”。
> 然而要成为一名高效的软件工程师，你还需要那些学校里没有教授过的技能。而本书将会教你这些技能。
> 撰写设计文档、如何维护旧代码、如何On-Call（待命）、如何规划你的工作以及如何与你的管理者和团队互动
> 当你能够安全地交付代码并与你的团队无缝协作时，你就会到达这个里程碑。
> 你知道如何使用集成开发环境(IDE)、构建系统、调试代码和测试框架。你熟悉持续集成、系统指标和监控、配置和打包系统。你积极主动地创建和改进测试代码。在做架构决策时，你会考虑到长期运维。
> 在模棱两可的情况下，你会主动寻求帮助并得到明确的结果。你能以建设性的方式提出问题和定义课题。
> 你会文档化你的工作。
> 重点并不是要写一份完美的文档，而是要写得足够多，以引发讨论，充实细节。这是坎宁安定律的一个应用，该定律认为：“在互联网上获得正确答案的最好方法并不是提出问题，而是发布错误的答案。”
> 了解如何编译、测试和部署代码。阅读那些提交代码的请求和代码评审意见
> 不要满足于你的第一版设计。反复斟酌，要随时做好准备，因为你的系统会随着时间的推移而不断变化。
> 你要开始学习在必要的维护和重构中间寻找平衡。不要试图重构一切。
> 能力的4个阶段：“无意识的无能力”(unconscious incompetence)、“有意识的无能力”(conscious incompetence)，“有意识的有能力”(conscious competence)和“无意识的有能力”(unconscious competence)。
> 我们还将准备一些提示，方便你在“万事都求人”和“独行侠”之间取得平衡
> 冒充者综合征和邓宁-克鲁格效应，这可能会导致新工程师感到自信不足或自信爆棚，
> 无论你是一名刚毕业的学生还是一名经验丰富的老手，如果你不学习，你就会落后。
> 因为你总会希望尽快将软件上线，而花时间阅读文档和摆弄工具却会让你慢下来。别担心，大家都预料到你会需要些时间来成长。前置学习是一项有价值的投资，许多公司会专门为新员工设计学习课程
> 错误难免会发生。每名工程师都有类似的故事。尽你所能，努力理解你在做什么，但要知道这种事情总会发生
> 错误是不可避免的。成为一名软件工程师的路途艰辛，我们有时会失败。这几乎是所有人都知道的事情。降低系统风险并使这些错误不那么致命是你的管理者和团队的工作。如果你失败了，也不要被击垮：写下经验教训，然后继续前行。
> 文档可能会过期，同事们也会忘记某些事情，但是实例代码是安全的，
> 请每周都花一部分时间去阅读。可供阅读的内容有很多：团队文档、设计文档、代码、积压的任务票、书籍、论文和技术网站。不要试图一下子把所有东西都读完。请从团队文档和设计文档入手。这些文档会就事情是如何组合在一起的给你一个整体的概念。要特别注意那些关于如何权衡取舍和背景的讨论。接下来你就可以深入研究那几个与你最初任务相关的子系统了
> 仔细研究代码的数据结构和算法
> 留意那些惯用写法和风格，也就是去学习“本地方言”(local dialect)
> 尝试自己寻找答案。即使你的同事知道答案，你也要付出努力，这样你会学到更多。如果你没有找到答案，当你寻求帮助时，你的调查仍然会成为你的起点
> 限制你研究一个问题时预期花费的时间。在你开始研究之前就应该设定好时间限制，这样可以鼓励你遵守这个限制，防止收益递减（研究最终会拖累生产性）。
> 如果你在第二个时限之后仍然找不到确定的答案，就应该及时止损并寻求帮助。及时止损需要自律和练习，因为你要对自己负责。
> 在提出问题时描述你已经知道的情况。不要只是分享你的原始笔记。简要地描述你所做的尝试和发现，这表明你已经花了很多时间去试图自己解决这个问题。这样做也会给别人一个回答你的起点。
> 在你设置的会议议程中应包括这个清单，不要只靠脑袋来记问题，也不要事前不做功课就来参加。
> 一般有两个常见的障碍会影响许多工程师，即“冒充者综合征”和邓宁-克鲁格效应。如果你了解这些现象是什么，以及如何克服它们，你会成长得更快。
> 他们总是到处批判公司的技术栈，抱怨代码的质量，贬低设计。他们确信自己的想法是正确的。他们的默认模式是直接回绝或无视反馈
> 当你浏览代码时，你就会注意到它的缺点。混乱的代码是变化的自然副作用，不要把代码的不整洁归咎于开发者。这种走向无序的趋势被称为软件的熵(software entropy)。
> 幸运的是，软件的熵可以被管理
> 本金是那些需要修复的原始不足。利息是随着代码的发展没有解决的潜在不足，因为实施了越来越复杂的变通方法。随着变通办法的复制和巩固，利息就会增加。复杂性蔓延开来，就会造成bug。未支付的技术债很常见，遗留代码里有很多这样的债务。
> 这种类型的债务更像是在出问题的领域反思学习或作为软件架构师成长的必经之路，而不是未做功课这么简单。健康的团队使用诸如项目回顾等做法来发现无心之债，并讨论何时以及是否偿还。
> 要边做边解决，着手去做小幅的重构。在小幅的、独立的提交(commit)和拉动请求(pull request)中推动问题的修改。
> 下面是讨论技术债的一个优秀的模板：1.按事实陈述情况；2.描述技术债的风险和成本；3.提出解决方案；4.讨论备选方案（不采取行动也是备选方案）；5.权衡利弊。
> 3.3 变更代码
变更代码和在新代码库中写代码完全不一样，你必须在不破坏现有行为的情况下进行这些修改。你必须理解其他开发者的想法，坚持原有的代码风格和设计模式。而且，你必须在工作中温和地改进代码库。
无论是添加新特性、重构、删除代码还是修复bug，变更代码的技术大体上一致。事实上，不同类型的变更经常被结合起来使用。所谓重构，是指在不改变软件行为的情况下改进内部代码结构。它经常发生在添加新特性的时候，因为它使新特性可以更容易地被添加。而在修复bug的过程中，则经常删除代码。
改变现有的大型代码库是一项需要经过多年甚至几十年锤炼的专业技能。下面的小技巧在你开始的时候就会帮助到你。
3.3.1 善于利用现有代码
> 改变现有的大型代码库是一项需要经过多年甚至几十年锤炼的专业技能
> 互联网上的编程传说经常引用童子军的原则：“住过的营地要比住之前更干净”。
> 当你修复错误或增加新的特性时，只清理有关联性的代码。不要不顾一切地去找“脏”代码，要“随缘”一些。
> 。在你的工作中，要随时定位有异味的代码。代码异味(code smell)是一个术语，专指那些不一定是bug，但采用了已知会导致问题的代码模式，通常“闻起来很怪”
> 。利用一切你所拥有的工具。如果你的编程语言有一个优秀的IDE，就去使用它。
> 重置你的分支，压缩你的提交，并在提交代码修改供评审之前写一份清晰的提交信息。
> 品在做某件事情时至少要比目前流行的方式好十倍。两倍或三倍的改进不足以让人们快速或大量地转向新事物。
> 所有的技术都会发生故障，但旧的东西以可预测的方式发生故障，新东西往往会以令人惊讶的方式发生故障。缺乏成熟度意味着更小的社区、更低的稳定性、更少的文档，以及更差的兼容性。新技术甚至在Stack Overflow[插图]上有更少的答案。
> 有时新技术会解决你公司的问题，有时则不会。要辨别何时使用新技术，需要明确的规则和经验。新技术的收益必须超过其成本。
> 不要以为重构工作会很轻松，这将是一个艰难的过程
> 编写拥有良好防御性的代码是一种对那些运行你的代码的人（包括你自己！）富有同情心的表现
> 现在都对类型提示和静态类型检查器有越来越强大的支持
> 代码清单4-1所示的Python 3.5的方法就使用了类型提示来接收和返回一个字符串。
> 如果一个参数应该大于0，那就要确保它大于0；如果一个参数是IP地址，那就要检查它是否是一个有效的IP地址。
> 计算机硬件并不总值得信赖，网络和磁盘可能会损坏数据。如果你需要强大的耐久性保证，使用校验和的方式来检查数据没有意外的变化。
> 也不要忽视安全问题，外部输入是危险的。恶意用户可能试图在输入中注入代码或SQL，或撑爆缓冲区以获得对你的应用程序的控制权限。使用成熟的类库和框架来防止跨站脚本攻击，总是强制转义输入的字符来防止SQL注入攻击。
> 如果一个内置的异常可以描述问题，就不要创建自定义的异常。开发人员有经验去处理现有的异常类型，他们会知道这些异常具体是什么意思。
> 当你创建自己的异常时，不要把它们弄得太通用。通用的异常很难处理，因为开发人员并不知道他们正面临什么样的具体问题。如果开发人员没有得到已发生错误的精确信息，他们就会迫使整个应用程序以失败结束，这将是一个重大的动作。对于你引发的异常类型的描述要尽可能具体，这样开发人员就能对程序失败做出适当的反应
> 跟踪这类错误是令人“抓狂”的——你修复了一个bug，却发现真正的问题出在上游。
> 谨慎的做法是使用一种叫作“退避”(backoff)的策略。退避会非线性地增加休眠时间（通常使用指数退避，如(retry number)^2）。
> 如果一个网络服务器发生了一起突发事件，而且所有的客户端也都同时经历了这起突发事件，那么就用同样的方法进行退避。
> 处理重试的最好方法是构建幂等系统。一个幂等的操作是可以被进行多次并且仍然产生相同结果的操作。
> 通过允许客户端单独为每个请求提供一个唯一ID的方式，远程API就可以变为幂等API。当客户端重试时，它提供的唯一ID与失败时的相同。如果该请求已经被处理过了，服务器可以移除重复的请求。让你的所有操作都成为幂等操作，这可大大简化系统的交互，同时也可消除一大类潜在的错误。
> 当故障发生后，要确保清理所有的资源，释放你不再需要的内存、数据结构、网络套接字和文件句柄。
> 一个资源已经接近其容量上限，就应该是一个WARN。每当你记录一个WARN时，应该对应一个你希望看到这个日志的人去采取的具体行动。
> 日志信息不应该包括任何私人数据，如密码、安全令牌、信用卡号码或电子邮件地址。
> 应用程序的系统指标可以被汇总到一个集中式可视化系统中，如Datadog、LogicMonitor或Prometheus。
> 分布式调用跟踪。对上游API的一次调用可能会导致对下游的数百次不同服务的RPC调用
> 对人友好的配置文件、环境变量和命令行参数是最常见的方法
> 通常动态配置带来的收益往往比不上它引入的复杂性，你需要仔细考虑运行过程中因为各种配置变化而产生的所有影响。它还会使你更难跟踪哪项配置被改变了，谁改变了它，以及它的值是什么，这些信息在调试运维问题时可能是至关重要的。它还会增加对其他分布式系统的外部依赖性。这听起来很简单，但重新启动一个进程来获取新的配置通常在操作上和架构上都更好一些。
> 不要盲目地从其他文件中复制配置（一个被称为船货崇拜的例子：在没有真正理解它们的作用或原理的情况下就复制东西）。
> 脚本化的工具很容易实现自动化。如果你打算构建一个基于用户界面的工具，那就把逻辑抽象成一个共享库或服务，这样基于CLI的工具也可以使用。
> left-pad的软件包消失后，成千上万的JavaScript项目开始无法编译。
> ● 唯一性(unique)：版本不应该被重复使用。构件会被分发、缓存，并被自动化工作流拉取。永远不要在现有版本下重新发布更改的代码。● 可比性(comparable)：版本应该帮助人们和工具对版本的优先顺序进行推断。当一个构建依赖于同一构件的多个版本时，可以使用优先顺序来解决冲突。● 信息性(informative)：版本信息区分了预先发布的代码和已发布的代码，将构建流水号与构件相关联，并设置了稳定性和兼容性的合理预期。
> 这是版本管理中最常用的方案之一。官方的SemVer规范可在其网站中找到。该规范定义了3个数字：主版本号、次版本号和补丁版本号（有时也称作微版本号）。这3个数字被合并为“主版本号.次版本号.补丁版本号”的版本号格式。httpclient版本4.3.6意味着主版本号、次版本号和补丁版本
> 比较常见的相依性地狱的罪魁祸首是循环依赖、钻石依赖和版本冲突。
> 在现实中，兼容性是一个“美丽的愿望”。项目经常在没有检查兼容性的情况下就发放版本，即使是自动化也不能完全保证其兼容性。
> 大多数团队会在合并代码的修改之前进行代码评审。高质量的代码评审文化有助于所有具有不同经验水平的工程师的成长，并促进他们对代码库的共同理解。糟糕的代码评审文化会抑制创新，减慢开发速度，并且导致滋生怨恨情绪。
> 评审整个代码库的变更可以确保不止一个人熟悉生产环境中代码的每一行，对代码库的共同理解有助于团队更有凝聚力地扩展代码。
> 不要执着于那些你提交评审的代码，要期待它在评审过程中发生变化，有时甚至是重大的变化
> 一些开发者通过提交代码评审的方式来触发持续集成(continuous integration，CI)系统来绕过这个问题，这是一种糟糕的做法。
> 不要试图让你的队友在预排会议中实际地进行代码评审，参加者应该把他们的评论留到未来真正的代码评审环节。预排会议的目的是帮助你的团队理解为什么要提出修改，并给他们一个良好的心理模型，以便他们可以自行去进行详细的代码评审。
> 从你的代码上得到的那些批评性的评论可能让你很难接受。切记应该保持一些情感上的距离——这些评审意见是针对代码
> 首先审视你自己的反应，你本能地保护你的代码只是因为你编写了它们，还是因为你的方式事实上更好？清楚地解释你的观点，如果你们还是不能达成一致，咨询一下你的管理者下一步该怎么做。团队处理代码评审冲突的方式各不相同，有的服从提交者，有的服从技术负责人，还有的服从小组的法定人数。应该遵循团队惯例。
> 在你的日历上划出代码评审时间。预定的评审时间会使你很容易继续你的其他任务，因为你知道你以后会有集中的时间段进行代码评审。这也会使你的评审保持高质量——当你有专门的时间时，你就不会对需要切换回其他任务而感到有那么大的压力。
> 你需要对代码修改的正确性、可实施性、可维护性、可读性和安全性提供反馈
> 如果你从阅读代码中学到了一些新的东西，请明确地传达给作者。
> 即使是一项令你讨厌的修改，你也可以对它说些好话——如果没有别的原因，就承认它的意图和努力。
> 代码评审通常在一个专门的UI中处理，比如GitHub中的拉取请求界面。不要忘记，代码评审本身也只是代码而已。你仍然可以迁出或下载那些拟议的修改，并在本地处理它们。
> 尊重正在进行的修改的范围。在你阅读的过程中，你会发现改进相邻代码的方法，并产生一些关于新特性的想法，不要坚持将这些修改作为现有评审的一部分来进行。另开一张任务票来改进代码，把工作留到以后。确定严格的范围将提高速度并保持增量更改。
> 你的团队可能把整个流程——从打包到展开，统称为发布(release)。他们可能把打包一个构件称为发布，而把构件交付下载的过程称为发行(publishing)。直到一个特性在生产环境中被打开时才能称其为被“发布”了，而在这之前的一切行动都是部署(deploy)。在本章中，我们将提到软件交付的4
> 构建(build)、发布、部署和展开(rollout)
> Gitflow使用开发分支、热修复分支和发布分支。
> 你应该尽可能频繁地发布。较长的发布周期给人一种错误的安全感：两次发布之间的漫长周期感觉像是有充足的时间来测试变化。在实践中，快速的发布会产生更稳定的软件，当发现bug时更容易修复。
> 每个周期的变化较少，所以每个版本的风险都较小。当一个bug出现在生产环境中时，在调试时要回顾的代码变化就会更少。代码在开发人员的头脑中是新鲜的，这将使bug更容易和更迅速地被修复。
> 发布经理使用加密密钥对构件进行签名，这样用户就可以验证下载的软件包是否来自Apache。
> Puppet、Salt、Ansible和Terraform等现成的解决方案可以与现有的工具集成，并且它们是专门为了自动化部署而设计的。
> 为了避免失败的那部分部署操作，应使部署要么全部完成要么什么都没做（即原子性）。
> 特性开关、熔断器、“摸黑启动”、“金丝雀部署”和“蓝绿部署”。
> 特性开关有时被用于A/B测试，这是一种测试用户对新特性反应的技术。如果以具有统计意义的方式对用户进行分组，用特性开关进行A/B测试是可行的。
> 金丝雀部署不同的是，流量的切换是原子化的，蓝色和绿色环境尽可能地保持一致
> 亚马逊的构建者库也是一个伟大的免费资源，可用于交付最佳实践。该库位于亚马逊构建者的主页，那上面有关于持续交付、自动部署和回滚的帖子。
> 然而，大概每名On-Call人员最终都会遇到一起运维事故（生产软件的关键问题）。事故是由自动监控系统发出的警报或由支持工程师观察到问题并报告给值班人员的。On-Call的开发人员必须对事故分流、缓解症状和最终解决。
当关键警报发生时，On-Call的开发人员会被呼叫。“呼叫”是手机出现之前的一种过时的称呼。现在，警报是通过聊天软件、电子邮件、电话或文本信息等渠道发出的。如果你像我们一样，不接听任何来自未知号码的电话，请确保将警报服务的电话号码添加到你的联系人白名单。
所有的On-Call轮换的工作都应该以交接开始和结束。上一名On-Call的开发人员总结当前的所有运维事故，并为下一名On-Call的开发人员提供任何未解决任务的背景。如果你已经很好地跟踪了你的工作，交接工作就不是什么大事了。
> 创建一个你在紧急情况下可以依赖的资源清单：可以直接链接到你的服务的关键仪表盘和运行手册、访问日志的说明、重要的聊天室，以及故障排除指南。创建一个单独的“On-Call”书签文件夹，并保持更新，这会很方便。与团队分享你的清单，以便其他人可以使用和改进它。
> ，开发人员会感到压力和变得暴躁——这是人的本性
> 简洁确保你的沟通容易被阅读和理解。如果你并不知道答案，就说出来；如果你知道答案，就大声说出来。回应请求要迅速。回应不一定代表解决方案。告诉请求者你已经看到了他们的请求，并确保你理解问题所在。
> 后续行动(follow-up)：对事故的根本原因——为什么会发生，进行调查。如果事故很严重，就会进行正式的事后调查，或进行回顾性调查。建立后续任务，以防止那个（或那些）根本原因的再次出现。团队要寻找流程、工具或文档中的任何漏洞。在所有的后续任务完成之前，相应事故的处理不应该被认为已经结束了
> 设计工作被分成两种活动：单独的深入思考和协作的小组讨论。研究、头脑风暴和写作构成了深度工作。设计讨论和对设计文件的评论构成了合作的部分。这个过程的有形产出是一份设计文档。
> 当你在撰写文档的过程中，你发现了更多的未知因素。你创建了一些小的原型来验证你的设计、回答问题，并帮助你在可行的替代方案中做出选择。你进行更多的研究，并请专家提供意见。你充实了设计文档的草稿
> 你现在处于圆锥体的顶部。你在你的设计中已经投入了大量的工作，而且对你的方案充满信心。你将设计方案在整个组织内传阅。安全、运维、相关的团队和架构师都需要了解你所承诺的变更，这不仅仅是为了提供反馈，也是为了更新他们对整个系统工作方式的心理模型。
> 询问利益相关者他们认为问题究竟是什么。这些利益相关者可能是你的管理者、队友、产品经理或技术负责人
> 不会在你锁定的整段时间内进行“设计”。你的大脑需要时间来放松：休息一下，给自己一个呼吸的空间；允许你的思想放松和游荡；去散步、泡茶、阅读、写作、画画。
> 并非每一项变更都需要设计文档，更不用说正式的设计评审过程了。你的组织可能有自己的指导方针。如果没有指导方针，就用这3个标准来决定是否需要设计文档。● 该项目将需要至少一个月的工程时间。● 这一变更将对软件的扩展和维护产生长期的影响。● 该变更将显著影响其他团队。
> 写作作为一项技能，就像其他技能一样，是通过实践来进步的。充分利用写作的机会——设计文档、电子邮件、代码评审意见——努力写得清晰。
> 不要让人惊讶你需要有礼貌地并且渐进地让人们了解你的设计方案。如果正式的设计文档是其他团队和技术负责人第一次了解你的工作，你就是在为自己的失败埋下伏笔。每一方都有不同的视角和不同的利益诉求，他们可能会对一份突然出现的、他们没有发言权的设计文档做出强烈的反应。
> 当一个问题特别多元或有争议时，要选择更大、更有包容性的头脑风暴会议。对于更直接的讨论，应保持较少的被邀请者人数，使谈话更容易进行。
> 会议结束后，以白板上的图片为指导，根据你的回忆写一份总结。把这些笔记发给与会者和其他相关的队友。
> [插图]
> 《软件设计的哲学》(A Philosophy of Software Design)中写到：“复杂性是与系统结构有关的东西，复杂性使人难以理解和修改系统。”按照奥斯特霍特的说法，复杂系统有两个特点：高依赖性和高隐蔽性
> 面对未来未知的需求，工程师们通常会选择下面两种策略中的一种：试图预判未来的需求，或者建立抽象模型作为逃生舱门，使后续的代码修改更容易。
> 避免过早优化，避免不必要的灵活抽象模型，以及避免最小可行产品(minimum viable product，MVP)所不需要的产品特性——你需要那些可以获得用户反馈的最低限度的功能集。
> 按技术领域进行分组的代码在单一业务领域内效果很好，但随着业务的发展，就会变得很混乱
> 个人和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划
> 一旦敏捷开发模型流行开来，“黑带忍者”、权威认证和流程顾问就会笼罩在一些组织之上。人们迷恋于“做敏捷”的“正确”方法，而往往损害了第一个原则：“个人和互动高于流程和工具”。
> 会让每个人都了解你的进展，让你负起责任和保持专
> 队友们围成一圈，介绍自上一次站会以来他们所做的工作，他们计划在未来做什么
> 你对公司的方向有什么疑问？你对组织变革有什么疑问？
> 反馈：我们可以在哪些方面做得更好？你对团队的计划流程有什么看法？你最大的技术难题是什么？你希望你能做什么而你却做不到？你最大的问题是什么？公司的最大问题是什么？你或团队中的其他人遇到了什么阻碍？职业生涯：你的管理者对你都有哪些职业建议？你有哪些可以改进的地方？你希望自己有哪些技能？你的长期目标是什么，你觉得你在这些目标上的进展如何？个人事务：你的生活中有什么新鲜事？你的管理者应该注意你的哪些个人问题？
> PPP中的每个P（进展、计划与问题）都有自己的小节。每个小节应该有3到5个要点，每个要点应该很简短，只有1到3个句子。
> 定义了目标（目的），并为每个目标附上衡量标准（关键结果）
> 在写自我评价时，不要凭记忆行事。记忆是不稳定的，你可能只关注某些难忘的项目。务必保有一份最新的在整个一年中完成的工作的清单——一份已完成的待办事项清单、一套PPP或一份“子弹日记”，以唤起你的记忆。看看你在公司的问题跟踪系统中已完成的任务。你完成了哪些里程碑、史诗和用户故事？已合并的代码拉动请求和代码评审也显示了你所做的工作。还有不要忘记你的非工程类的项目，辅导实习生、代码评审、参与面试、博客文章、演讲、文档——所有的这些都应该被认可，使用你所拥有的一切来写一份诚实的自我评价。
> 可以使用一对一面谈的方式来获得反馈。
> 不要听信表面上的反馈。你的管理者仅仅是视角之一（尽管是一个重要的视角），试着把管理者的反馈纳入你的观点，而不是直接采用管理者的反馈
> 我们今天能谈谈职业生涯的路径吗？老实说，我不确定我能看到自己五年后在哪里，甚至我的选择是什么。你看到的一些常见的职业路径是什么，它们之间有什么区别吗？我很喜欢我目前的项目，但我也对安全领域感到好奇。是否有机会可以让我做一些与安全有关的工作呢？
> 培养T型技能，参加工程师训练营，主导晋升过程，不要过于频繁地更换工作，并多自我调节。
> 软件工程有许多专业领域：前端、后端、运维、数据仓库和机器学习等。“T型”工程师在大多数领域内都能有效地工作，并且至少是某一个领域的专家。
> 你的职业生涯是一场马拉松，而不是短跑冲刺——你有几十年的时间。给自己定下节奏，享受这段旅程吧！
> 与你喜欢的人一起工作并解决你所热衷的问题，你就可以完成伟大的事情
## 笔记
> 技术债
💭 技术债务大多是时空局限性带来的产物，整体来是一个熵增的过程。别妄想永远消除技术债务，只需要平时定期审计，重构，从而维持一个相对平衡的状态即可。
> On-Call
💭 处理故障首先确定范围，然后定义性质。
> 一名成功的软件工程师究竟是什么样子的呢？以及如何成为一名成功的软件工程师呢？
💭 活在当下，着眼未来
> 如果你的公司没有安排新人入职培训，那需要你自己去向你的管理者要一份公司的“组织架构图”，了解清楚谁负责什么，谁向谁汇报，都有哪些不同的部门，以及它们之间的关系。记得做好笔记。
💭 公司的战略方向，核心业务，市场地位，组织架构都是入职之后需要迅速了解，代入的重要因素！
> 这样做的目的是让你去了解那些步骤，而不是去打动谁。
💭 充分把握生产流程中的每一个环节
> 本节将列举各种各样的学习方法。切勿试图同时去做本章中列出的所有事情！因为那样会让你感到倦怠。切记善用个人的时间——虽然说持续进步非常重要，但是把所有清醒的时间都花在工作上是不健康的。
💭 一定要学会摸鱼学习，这才是自己的！😎
> 错误是不可避免的。成为一名软件工程师的路途艰辛，我们有时会失败。这几乎是所有人都知道的事情。降低系统风险并使这些错误不那么致命是你的管理者和团队的工作。如果你失败了，也不要被击垮：写下经验教训，然后继续前行。
💭 兼容性，容错性，而不是矫枉过正，一棒子打死🔨😥
> ，潘卡给出了一些背景，描述了问题，告诉艾丽斯他已经尝试了什么，然后才请求帮助。
💭 场景，因素，问题，目的，结果
> 谨慎的、有意的技术债（右上）是技术债的典型形式：在代码的已知不足和交付速度之间进行务实的取舍。只要团队有规划地解决这个问题，这就是好的债务。
💭 平衡点
> 不要把你的呼吁建立在价值判断上（“这代码又老又难看”），将重点放在技术债的成本和修复它带来的好处上。
💭 不能光说，也得去做
> 在不影响整个项目持续运转的情况下[插图]要持续地重构工程，这样重构的成本就会平摊在多次的版本更迭中。
💭 隐形成本
> 不要因为你不喜欢你公司（或行业）的标准就忽视它们，编写非标准的代码意味着它将无法适应公司的环境。因为持续集成检查、IDE插件、单元测试、代码校验、日志聚合工具、指标仪表盘和数据管道都已经集成在一起了，你自定义的方案肯定会代价高昂。
💭 系统化，标准化的技术设施建设才可以让万丈高楼平地起
> 分叉(fork)是对一个代码库进行完整的、独立的复制，分叉之后的代码库有自己的主干、分支和标签。在GitHub这样的代码共享平台上，在向上游代码库提交拉动请求之前，就可以分叉上游代码库。分叉操作可以让那些对主代码库没有写入权限的人仍然可以对项目做出贡献，这是一种正常而健康的做法。
💭 目前分叉可以划分为硬分叉和软分叉，硬分叉则是完全独立出来，上下游无关。软分叉则是为了满足某些非社区主流特性，上下游关联。
> [插图]
💭 生活不是一天天变好的，日子也不是一天过完的。病来如山倒，病去如抽丝，技术债务根本无法消除，只能渐进式改进，尽可能地维持平衡。
> 配置即代码(configuration as code，CAC)的哲学认为，配置应该受到与代码同样严格的要求。配置错误可能是灾难性的，一个错误的整数或缺失的参数就可以毁掉一个应用程序。
💭 配置同样需要接受版本控制
> 优秀的代码评审可以作为一个教学工具，传播认识，记录实现的决策，并提供代码的更改记录以确保安全性与合规性。
💭 信息对称，深度交流
> 代码修改由准备、提交、评审、最后批准和合并这几个环节组成。
💭 流程化标准化管理建设
> 每个人的记忆都会“消失”，你回应得越快，你得到他人回应的速度就越快。
💭 不要考虑，直接去干
> 一个快捷方式或软链接就可以被原子化地翻转。
💭 Linux 软连接
> 摸黑启动的软件其实仍然启用了，代码也被调用了，只是结果被丢掉了。摸黑启动可帮助开发者和运维人员在生产环境中了解他们的软件，对用户的影响最小。
💭 镜像流量
> 随时响应”并不意味着立即放下你正在做的事情来解决最新的问题。对于许多请求，完全可以先承认你已经收到了询问，并回答你应该在什么时候能看一下这个问题：“我现在正在协助其他人，我可以在15分钟内给您答复吗？”一般来说，人们希望On-Call工程师能做出快速反应，但不一定需要快速解决问题。
💭 先承接情绪价值
> 有些支持请求异常紧急，而有些请求则在一周内完成就可以。如果你无法判断一个请求的紧急程度，请询问该请求的影响是什么。影响范围将决定优先级。如果你不认可请求者对于某个问题的优先级次序的看法，请与你的管理者讨论一下。
💭 划分范围，确定性质。
> 它影响了多少人，有多大的危害性？在SLI和触发警报的指标（如果适用的话）的帮助下，使用你公司的优先级分类和SLO/SLA定义来确定问题的优先级。
💭 划范围，定性质。
> 你在应急方案的阶段目标是降低问题的影响。应急方案并不是要彻底地解决这个问题，而是要降低其严重性。修复一个问题可能需要很多时间，而应急方案通常可以很快完成。
💭 尽可能的减少损失，影响
> 工程师们从原来的连接器中移除所有健康的数据流，试图重现这个问题。
💭 复现错误
> 负责连接器的工程经理安排了后续工作，On-Call工程师撰写了一份“尸检”文件的草稿。安排一次“尸检”会议。最终，通过“尸检”这一过程，新开了3张任务票，分别调查为什么APM要使用消息头、为什么连接器的消费者节点不能反序列化、为什么手动的消费者节点不能输出空字符串的头。
任何事故都是一件大事，所以需要后续行动来继续跟进。目的是从事故中学习，防止它再次发生。要写一份事后总结的文档，并进行评审，同时开启新任务以防止其再次发生。
💭 复盘总结
> 你的首要任务是定义和理解你要解决的那个（或那些）问题。你需要了解问题的边界，以便知道如何解决它，并避免构建错误的东西。
💭 理解问题，定义性质，确定边界🤔
> 当你写代码的时候，要使用最小惊讶原则和封装原则。这些设计原则将使你的代码易于演进。
💭 封装，继承，多态三板斧
> 保持代码灵活性的最佳方法之一是减少代码的总量。对于你所构建的一切，问问自己哪些是绝对必要的，其余的就舍弃掉。
💭 断舍离
> 解决大局观上的偏差
💭 不能掉队
> 如果你已经给出了反馈意见，并保持了耐心，但事情仍然没有进展，那就起身离开。
💭 无法形成正反馈，就需要接受无尽的消极。
> 一名软件工程师的职业曲线是漫长的，本书将带你走完旅程的开端。接在后面的是终身学习、技术领导力，甚至可能是走上管理岗位或创业。无论你选择何种职业路径，你都必须继续成长。
💭 持续学习，技术领导(•̀ᴗ•́)و̑̑
> 了解晋升的流程，确保你的工作是有价值的和可见的，当你认为自己接近下一个级别时，要大声说出来。
💭 主动出击
> 反过来说，不要待得太久。工作僵化、停滞不前是改变现状的正当理由。在一家公司工作时间长的工程师自然会成为“历史学家”，他们教导工程师事情是如何运转的、谁知道什么，以及为什么事情是按照他们的方式完成的。这样的知识是有价值的，甚至是一名主任工程师职责的一部分，但如果你的价值更多来自过去的工作而不是现在的贡献，那么它就会阻碍你的成长。更换公司并在一个新的环境中找到自己，可以重启你的成长。
💭 谨防温水煮青蛙
## 书评
> ✨其实应该更早一些读到这本书。 实际工作中最好是在职场的第二年开始的时候，首先经过一年的成长已经度过了新手期，同时经过这本书的指导，可以让我们更容易地走好下一阶段的路，从而最低成本试错，减少走弯路，争取到达新高峰！
## 点评