Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederxilidou.com
犀利豆的博客
Get the latest updates from 犀利豆的博客 directly as they happen.
Follow now 17 followers
Latest posts
Last updated about 3 years ago
《SRE google 运维解密》读书笔记 （六）
about 3 years ago
测试可靠性预测信息准确的前提：系统完全没有改变充分描述整个系统的改变测试是一个用来证明变更前系统的某些领域相等的手段。软件测试的类型传统测试生产测试传统测试单元测试集成测试系统测试冒烟测试性能测试回归测试每个测试都有成本，通常来说单元测试时间成本低 如果要将完整的功能架设起来测试，通常需要几个小时。关注测试成本，是软件提升效率的重要因素。生产测试生产测试和一个已经部署在生产环境的业务系统直接交互，而不是运行在封闭的测试环境。有时候称为黑盒测试配置测试压力测试金丝雀测试一小部分机器先升级，保持一定的孵化期。将代码置于比较难以预测的用户流量下需要能够快速的回滚创造一个构建和测试环境测试的重点集中在用最小力气得到最大收益的地方划分优先级寻找关键函数关键类寻找提供给其他团队的 API发布前，通过冒烟测试寻找到的 bug 变成测试用例建立良好的测试基础设施追踪代码变更每次代码改变就进行构建精确的构建，只构建修改的地方，并执行修改代码的单侧使用工具可视化或者量化测试覆盖度和钱相关的系统需要更多测试大规模测试单元测试需要有针对性的覆盖组件中相互依赖的部分测试大规模使用的工具针对灾难的测试灾难恢复工具被精心设计为离线运行计算出一个可记录状态，等同于服务完全停止的状态将可记录的状态推送给非灾难验证工具支持常见的发布安全边界检查对速度的渴求有的时候测试的结???会在重复运行下发生改变。所以需要针对某些场景，重复运行一定数量的测试。发布到生产环境通常，生产环境的配置文件容易被测试忽略。集成使用解释性语言编写配置文件是有风险的。程序的执行时间没有上限，需要加入截止时间检查。使用成熟的语法（YAML）和大量测试的解析器。生产环境探针测试机制是对确定的数据检验系统行为是否可以接受。监控机制择时在未知数据输入下系统行为是否可以接受。已知的正确请求应该成功，已知的错误请求应该失败。重放已知请求观察系统是否正常。（感觉应该是书翻译的问题所谓的探针应该是 mock 服务。mock 服务部署在生产环境 。在确定的入参下，有确定的返回值。调用方可以使用这个探针进行测试）小结测试是工程师提高可靠性投入回报比较高的手段。
《SRE google 运维解密》读书笔记 （五）
about 3 years ago
测试可靠性预测信息准确的前提：系统完全没有改变充分描述整个系统的改变测试是一个用来证明变更前系统的某些领域相等的手段。软件测试的类型传统测试生产测试传统测试单元测试集成测试系统测试冒烟测试性能测试回归测试每个测试都有成本，通常来说单元测试时间成本低 如果要将完整的功能架设起来测试，通常需要几个小时。关注测试成本，是软件提升效率的重要因素。生产测试生产次数和一个已经部署在生产环境的业务系统直接交互。有时候称为黑盒测试配置测试压力测试金丝雀测试一小部分机器先升级，保持一定的孵化期。将代码置于比较难以预测的用户流量下需要能够快速的回滚创造一个构建和测试环境测试的重点集中在用最小力气得到最大收益的地方划分优先级寻找关键函数关键类寻找提供给其他团队的 API发布前，通过冒烟测试寻找到的 bug 变成测试用例建立良好的测试基础设施追踪代码变更每次代码改变就进行构建精确的构建，只构建修改的地方，并执行修改代码的单侧使用工具可视化或者量化测试覆盖度和钱相关的系统需要更多测试大规模测试单元测试需要有针对性的覆盖组件中相互依赖的部分测试大规模使用的工具针对灾难的测试灾难恢复工具被精心实际为离线运行计算出一个可记录状态，等同于服务完全停止的状态将可记录的转态推送给非灾难验证工具支持常见的发布安全边界检查对速度的渴求有的时候测试的结果会在重复运???下发生改变。所以需要正对某些场景，重复运行一定数量的测试。发布到生产环境通常，生产环境的配置文件容易被测试忽略。集成使用解释性语言编写配置文件是有风险的。程序的执行时间没有上限，需要加入截止时间检查。使用成熟的语法（YAML）和大量测试的解析器。生产环境探针测试机制是对确定的数据检验系统行为是否可以接受。监控机制择时在未知数据输入下系统行为是否可以接受。已知的正确请求应该成功，已知的错误请求应该失败。重放已知请求观察系统是否正常。（感觉应该是书翻译的问题所谓的探针应该是 mock 服务。mock 服务部署在生产环境 。在确定的入参下，有确定的返回值。调用方可以使用这个探针进行测试）小结测试是工程师提高可靠性投入回报比比较高的手段。
《SRE google 运维解密》读书笔记 （四）
about 3 years ago
事后总结：从失败中学习哲学保证事故能够被记录下来，理清所有根源问题。确保实施有效的措施是的未来重现的几率和影响得以降低，甚至避免。书写事后总结不是一种惩罚，而是整个公司的一次学习机会。需要书写的标准：用户可见的宕机或者服务质量下载到一定标准任何形式的数据丢失on-call 工程师需要人工介入问题解决耗时超过一定限制监控问题事后总监“对事不对人”。必须关注如何定位造成这次事件的根本问题。而不是指责某个人或者某个团队的错误或者不恰当。事后总结系统性，逻辑性的讨论为什么会在事故过程中获得错误的的信息，才能更好的建立预防措施，防止问题再现。最佳实践：避免指责，提供建设性意见协作和知识共享实时协作开放的评论邮件通知包含内容：关键的灾难数据是否收集保存起来了本次事故的影响评估是否完整造成事故的根源问题是否足够深入文档记录的任务优先级是否合理，是否及时解决了根源问题事故处理过程是否共享给了相关部门最佳实践，所有的事后总结都要评审建立事后总结文化本月最佳总结事后总结小组事后总结阅读俱乐部命运之轮可以对已经发生的事故进行演练最佳实践：公开奖励做正确事的人最佳实践：收集关于事后总结有效性的反馈跟踪故障聚合加标签分析报告和公告
《SRE google 运维解密》读书笔记 （三）
about 3 years ago
应急事件响应测试导致的事故SRE 故意破坏系统，利用这些测试发现系统的薄弱地方。在某次测试中发现了额外的系统依赖。响应终止测试用以前 测试过的方法 回滚了数据找到开发者修复了相关问题制定了周期性测试机制来保证问题不重现事后总结好的方面：事先沟通，有足够信息推测是测试造成的问题。快速恢复了系统。遗留一个代办，彻底修复问题。制定了周期性的测试流程。不好的方面：虽然评估了，但是还是发生了问题没有正确遵守响应流程没有测试“回滚机制”，发生问题后回滚机制失效。变更导致的事故某个周五，某个配置文件推送到所有的服务器。触发了 bug。响应各个系统开始报警on-call 工程师前往灾难安全屋。（有google 生产环境专线）5 分钟以后发布这个配置的工程师发现问题，回滚发布某些服务由于这次发布，触发了别的 bug 一小时后才回复事后总结好的方面：监控系统及时报告问题问题被检测后，应急流程处理得当。SRE 要保持一些可靠的，低成本的访问系统Google 还有命令行工具和其他访问方式确保能够在其他条件无法访问的时候进行更新和变更回滚。且要频繁测试，让工程师熟悉他们。限速机制，限制了错误的扩散。抑制了崩溃的速度。从中学到的：变更经过了完整的部署测试没有触发...
《SRE google 运维解密》读书笔记 （二）
about 3 years ago
有效的故障排查手段理论：反复采用假设排除手段的过程：不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除常见的陷阱关注的错误的系统现象，或者错误地理解了系统现象的含义。不能正确的修改系统的配置信息，输入信息或者系统运行环境。将问题过早的归结为极为不可能的因素，或者之前曾经发生德国的问题试图解决与当前问题相关的一些问题，却没有认识到只是巧合。实践故障报告故障报告不鼓励直接汇报给具体的某个人，这样会导致压力集中在几个问题汇报人熟悉的团队成员。而不是质保人员。需要保证每一个故障报告都有调查的历史和解决方案。定位大型问题，不要立即开始排查问题，尽快找到问题的根源。正确的做法是，尽最大可能使系统回复。（同时尽量保存报错的现场供事后调查复盘）检查需要检查系统中每个组件的工作状态，以便了解系统是不是在正常工作。理想情况下监控可以提供相应指标。日志很重要，了解系统某个时间在干啥。将日志结构化，可以保存更长时间多级记录日志很重要，尤其可以动态调整日志级别在日志系统中支持过滤条件诊断简化和缩略对于大型系统，逐级查询问题过于耗时，尝试使用二分法。What 、Where 、Why最后一次变更变更是引起问题的最大来源有针对性的诊断测试和修复理想的测试应该具有互斥性，一个测试可以推翻一组假设先测试最可能的问题某些测试可能带来误导性的结果执行测试可能会带来副作用神奇的负面结果所谓负面结果，就是一项试验中不符合预期的结果负面结果不应该被忽略负面结果需要被记录，供后来人查阅。比如压测不通过的报告工具和方法可能超越目前的试验，为未来的工作提供帮助公布负面结果有利于挺升行业的数据驱动风气公布结果负面结果并不是失败负面结果并非没有价值良好设计的试验是有价值的，而不是有正向结果的试验才有价值治愈理想情况下，可能把错误原因减少到了一个。下一步复现问题。然后修复问题如果一旦解决了某个问题，需要将如何定位问题，如何修复问题，如何防止问题再次发生。进行记录作为事后总结记录。使故障排查更简单增加系统的可观察性。为每个系统增加白盒监控和结构化日志利用成熟的，观察性好的组件接口设计系统
《SRE google 运维解密》读书笔记 （一）
about 3 years ago
新财年换了领导，管理风格也有一些区别。在团队内增加了一个 SRE 的职位。这一财年我将会承担一部分 SRE 的工作。之前作为开发者，总的来说从开发的角度来思考系统的稳定性。现在需要从更高更全面的角度来思考和理解站点的稳定性。上网研究了一番，SRE 是 google 的一个职位同时 SRE 也是一套 google 总结出来的站点稳定性的方法论。所以找来了《SRE...
2021 总结
over 3 years ago
2021 就这么结束了。家今年我做爸爸了。今年九月，迎来了我们家的小朋友。豆嫂从怀孕一路走来。如打怪升级一样。一关一关的过，颇为不容易。豆嫂孕早期孕吐严重，某天在地铁上没吃早饭，低血糖晕倒在地铁上，还好我在身边。周围的好心人都把自己的零食给了我们。下车后豆嫂把手里的一捧零食吃完以后，才重新坐上地铁上去上班。小朋友在肚子里总是不安分，总是脐带绕颈。时而一圈，时而两圈。九月的最后一次产检。调皮的小朋友臀位。没有正常入盆，只能剖腹产。小朋友出生那天，五点起来给豆嫂煮了小米粥。吃完以后，又睡了一会。八点把豆嫂送到医院准备手术。产科大夫，麻醉大夫分别告知了风险。我在知情同意书上签了字豆嫂进了手术室，我在手术室外面焦虑的不行，一圈一圈的走。就在彻底走不动的时候。手术室的门打开了，护士把我叫了过去，轻轻的掀开了蓝色的无菌布。一个粉白粉白的小生命出现在我的眼前。看了一眼小朋友。小朋友就被推进了新生儿室。我站在门口，隔着毛玻璃看着里面护士忙碌的影子，突然一股暖流充满了全身，眼睛也湿润了，我做爸爸了。由于疫情，医院全封闭管理，我并没有看到豆嫂。豆嫂说，麻醉过后特别冷，伤口特别疼。本以为一切结束了。稍微放松一点准备回家。在路上又被叫回了医院。医生上来就交代，血氧不足，哭声不正常，有风险。瞬间天旋地转，脚如灌铅。艰难的挪到了楼梯边，坐在楼梯上，给家里人打电话。下午，吸了氧的小朋友终于恢复正常。欢迎这个小生命来到这个世界，希望你能够健康快乐的成长，身体强壮，取小名“壮壮”。之后，去月子中心。出月子。满一百天去“中国照相馆”拍了纪念照。现在小朋友正躺在自己的小床上沉沉的睡去。呼吸均匀。大概再过两个小时又会饿得哇哇大哭，要喝奶了。车今年我在北京有自己的车了。今年为了照顾孕妇的出行。买了一辆车。还记得提车那天激动的几乎睡不着。坐在家里都忍不住到地库看了又看。现在回想起来自己小时候最爱的的汽车玩具，应该就是一辆 E30 平台的宝马三系。爱车的我终于在 31 岁生日前有了自己的第一辆车，而且是在北京。前几天，某人把车撞到了路边的墩子，更换前杠，保险没白买。旅行今年只去了稻城亚丁。海拔 4700 米的壮美雪山。无限风光在险峰。吸光了 4 瓶氧气，终于爬到了牛奶海。总体来说???路高反都是值得的。投资今年我没有亏钱。今年的投资居然没有亏钱。没有最热点新能源赛道。跟着长赢计划慢慢布局。一种踏实的感觉。不急不躁，踏踏实实的，多大点事。中丐互怜被锤，但是中证 500 在涨啊。配置分散，降低风险，控制回撤，是我今年的投资的体会。内心平和今年我没有去年焦虑。信息焦虑在...