加油💪（抽我抽我）

从哪里来，到哪里去，例如：贫僧自东土大唐而来，去往西天拜佛求经

OKR 是一种管理工具，为了自上而下明确方向、自下而上对齐目标。绩效是对结果的衡量，让多付出高贡献的人有更好的回报。这些管理手段在理念设计的初衷都是好的，但遭不住人性和社会的复杂考验

仔细看了一下婚俗，楼主是台州的吧

她跟我问路的

中医体系里有很多被验证有效的医学经验，例如部份中药（青蒿素）、推拿按摩、养生观念，它们也被现代医学逐渐验证和吸收。

中医更大的问题是成分复杂，缺乏标准化和对照实验，疗效被夸大（有些甚至能治癌症），副作用被忽视（尚不明确的不良反应）。面对这种糟粕，上世纪的鲁迅就已经不信了。。。

结婚时候婚礼要办吗，生娃之后满月酒要办吗，死了之后葬礼要办吗，这不都是同一个问题吗？

清明节还要扫墓吗，中元节还要祭祖吗，中秋节还要和家人团聚吗。。。不认同这些文化习俗，自身实力足够强大，能够和家族群体对抗，那就不办，但是人生除去生死，还能有几件重要的事情呢。。我的意见是，流程和仪式可以从简，但尽量还是要有。

我自己的婚礼，没有司仪没有舞台，是家里长辈主持的，接亲之后三下拜堂，大家就进棚吃席了。在轮桌敬酒，送别亲朋好友之后，晚上和我老婆一起给父母端茶，我俩自此就都改口不再喊对方父母叔叔阿姨了。仅供参考。

周报内容里不就有这些项目过程吗，需求背景-业务价值-技术方案-问题挑战-上线效果-复盘分析。简历和周报的内容都是总结性的，本质上没太大区别，AI 能整理这些吗

00:24 购物车功能已经恢复，但是下单支付被限流了，我挤了好久，终于挤进来了。。
https://i.imgur.com/vqyHcHv.png

我选择留着的理由是，万一哪天烧伤或者其它意外情况，需要植皮的时候，可以割掉拿来用一下。。

补偿到位，就没有什么问题。

但是楼主你要知道，工作之后步入职场，是需要和人共处共事的，并且这是一件在退休之前，都是进行时态的事情。向上明确事项目标、管理老板预期，向下带着团队拼搏、积极争取利益，这些和编程毫不相关的事情，但在职场中都是非常重要的，也是学校不曾开课教学的。要多抬头看路，别只低头拉车。

在团队里兼职做稳定性保障相关的工作，有一二年了吧，有一点经验和思考，做些总结和输出吧，欢迎指正。

首先要明确对系统的稳定性保障，并非是完全不能出现问题。越是复杂庞大的系统，就越有可能出现问题。参考云厂商在提供服务的时候，会有服务等级协议 SLA ，一般承诺可用性不低于 99.9%，但不会是 100%。所以在做稳定性保障之前，要先容忍不稳定的问题的发生。

其次要知道对系统做稳定性建设，是一件螺旋向上和持续优化的事情，而非一步到位就万事大吉了。这个月的问题数量比上个月少，这周告警认领率比上周高，这次故障影响面比上次小等等，都可以算作稳定性建设的成果。

回到主题。限流降级确实重要，但当做这些措施的时候，问题已经发生了。有没有一种方式，可以完全避免问题的发生呢，举个例子：当一个危险变更上线的时候，在多重审核机制下，被其他同事识别风险并阻断流程，能不能减少一次线上故障呢。

鸟瞰稳定性保障这件事，从时间维度可以分为事前->事中->事后三个节点，事前尽可能预防，事中及时高效处理，事后再做积极复盘。

在事前的预防阶段，首先要做的就是明确核心业务的核心链路，隔离故障影响面的带来直接效果会是最好的。要为其定制高可用的保障方案，例如历史代码的技术债务清理、应用独立集群和高规格部署、流量高峰期的弹性伸缩配置、避免与非核心业务共享存储资源、设计一套保障 VIP 用户体验的灾备通道流程等等。最具价值的业务流程自然是我们保障工作的重点。当然还有研发规范、变更管控、风险巡检、压测演练等这些日常需要经常执行的事情，甚至可以定期举办一些带奖品的简单考试，使稳定性的风险意识人人具备。

在事中的处理阶段，大部分人都存在一个误区：处理线上问题的时候，定位根因永远不是第一优先级，快速恢复业务才是。举个例子：在杭州自来水异味的事件中，排查臭味来源不是第一优先级，快速恢复居民正常供水才是，毕竟没有人会想喝一周时间的藻类降解物的自来水。为了使业务快速恢复正常，变更回滚、扩容升配、应急预案、必要的熔断限流降级等等，该用的措施就该及时用上，不熟悉业务的值班人员也该紧急联系业务老手才是。

另外，与问题没有被高效处置来说，更令人可怕的是问题没有被及时发现，毕竟没有人会想经历一次毫不知情的屎到淋头的感觉。监控和告警是大型应用系统不可或缺的一部分，除了机器水位指标，关键业务指标才是更加需要被关注的。核心指标的异常波动需要结合 IM 或者电话等能力，做到第一时间触达至正确的人，并且要搭配合理的升级机制，非核心指标的短暂波动要尽可能地减少干扰，让有限的精力始终保持在核心的业务上。

还有，对问题的处理效率是减少业务影响面的关键因素，可以按照问题发现->处置->恢复分为三个阶段，给每个阶段定一个耗时指标 MTTR ，例如五分钟发现、五分钟处置、十分钟恢复，每次问题处理过程中记录这些耗时，存在几次未达成是可以接受的，但要保持整体趋势往这个方向前行。

在事后的复盘阶段，需要注意避免定级定责带来的撕逼甩锅，要从做好保障和避免再次发生的角度来推进。每次复盘的知识库要沉淀，改进项要及时跟踪，避免这次复盘的问题根因，又再次出现。

最后再说，稳定性建设是一个高维度跨团队的事情，需要从上而下地和各方协作，才能最终执行到位。虽然说了很多方法论，但都是高屋建瓴的话语，我深知稳定性保障的难做，希望对楼主有所帮助吧。

我比较喜欢 Kotlin

规范的公司都会有明确的员工激励机制，优秀个人/团队/项目奖、年终奖、晋升之类，这些事情在面试时候就可以和 hr 问清楚

su7 的 hud 投影和前车尾灯重合的时候，眼睛都要看瞎了

国际金价，机场流量，up 主粉丝数。。
https://i.imgur.com/LRD5BmY.png