导读
本文将断续、松散的记录，楼主在运维管理和工作实施中的一些思考。
技术
2024.05.22 AGI能否确定性决策
人脑如何做出确定性决策？常见的方式有，
1、策略模式：遇到X现象，则执行Y动作。指标+阈值=>动作，强确定性 2、选择模式：多维打分，推荐得分最高的动作。类似人类决策过程，弱确定性
在选择模式下，人脑做出的决策也有不确定性。模拟人脑的AGI，大概率也做不到确定性决策。
这样看，确定性决策目前只有策略模式这一个选项。
2024.03.21 演练的哲学基础
类似科学实验，演练的哲学基础是可证伪性。演练通过则继续保持，演练不通过则系统一定无效。
2024.01.10 技术运营需要高阶投入
技术运营缺少高阶参与实施，这种做法非常不可取。
技术运营，事前需要顶层设计，这一点通常能达成共识；事中需要顶层投入、把控方向，这一点通常会被忽略。
比如，业务形态演进的情况下，技术运营无法完全固化，除低阶执行琐碎Toils外，还需要高阶审时度势、ReDesign顶层，否则技术运营模型就会逐渐劣化。
2023.12.13 工程师的创意美学
好的工程师，用工程的方法、解决技术问题。
杰出的工程师，善于跨界连结工程、组织、美学、科学等多个学科，创意地解决问题。会创造的工程师，更可爱。
2023.12.02 亚马逊的俭约架构
软件需求分为功能需求、非功能需求。功能需求，包括可用性、可扩展、可维护、可移植等。非功能需求，包括安全、合规、成本等，近似基础设施领域的运营。
俭约架构，目的是提升功能性价值、降低非功能性消耗。亚马逊的侧重点是「功能需求的开源」，原文是「俭约是为了最大限度提升价值、而不只是尽可能控制支出，因此在必须得花的钱上别吝啬」，这个说法符合云厂商的利益。对比而言，企业则更侧重「非功能需求的节流」，FinOps也好、降本增效也罢，首要目标是降低运营消耗、而不是提升功能价值，因为此时的企业往往成长预期不足。
不论如何，俭约架构这个提法很有意义，某种意义上画出了降本增效的架构底线、防止望文生义地竭泽而渔。
文献地址：这里
2023.09.20 基建中的业务思维
把基础设施当做业务来做，把基础设施子方向当做业务来做，不论横纵。
最近两年一直在如此实践，效果挺好。最近听到同行有类似的表述，心有戚戚、坚定了心智。这位同行经历过业务、存储、安全、架构等多个方向，视野非常完整。而自己整个职业生涯都在基础设施、视野受限，期待有一天能亲耕业务、睁眼看世界。
2023.09.08 高效建设技术能力
开源二开、采买二开，是建设技术能力的高效路径。
开源二开，通常遵循7分复用、3分自建的原则，尽量紧跟迭代的复用、避免魔改。
采买二开，如公共云，也要遵循9分使用、1分自建的原则。大部分时候，外采二开的问题不是自建太多、而是没有自建意识，云服务提供方最后沦落为管理员。
2023.08.16 CCF闭门会的启示
公共云本质，是：聚合(aggregation)+超卖(oversell)。公共云靠规模效应赚钱存活。
指标即目标，发掘一个能够表征目标的指标、然后做好指标度量，就能实现目标管理的数字化。例如，公共云的超卖率、滴滴打成的单位成本。
2023.07.28 观测和技术体系的关系
观测的关键，在于数据质量、场景抽象。数据质量是起点，决定了场景的长期维护成本，因此数据质量是观测体系的第一个重点。
观测处在技术体系的下游，其数据质量取决于上游建设，比如上游的资源标准、组件标准、服务治理框架等等。观测是技术体系的配套能力、是螺丝钉，观测要能融入现有技术体系，以观测为中心造烟囱无异于空中楼阁、很难拿到效果。
观测起源于技术领域，但也能超越技术领域。比如，观测数据经过维度聚合(数据处理)、可以用于商业分析等业务领域。观测产品会吸纳数据处理能力，实时和离线在技术、功能上的分界线也将更加模糊。
BTW。ToB领域，做技术体系治理很难赚到钱(业务组织属性太重)，观测产品有共性能赚钱、但无法从根本上解决上下游的问题，非常矛盾。如何优雅的衔接技术体系和观测产品呢？观测产品制定标准、开放接口、广泛适配，为技术体系提供低成本的接入能力，这可能是一条正确路，单纯增强产品能力可能会掩盖技术体系的自有问题。
2023.06.06 服务链路有超强黏性
众多服务组成了一张网，一旦成型就很难革新。一方面，服务链路有超强黏性，一个点的革新会调动一条链、甚至整张网。另一方面，服务链路革新的ROI较低，业务价值较小。
因此，运营治理应避免服务链路改造，如果不能、也应逻辑切分，运营的归运营、服务的归服务。
2023.05.09 效率和质量的目标之辩
卓越绩效的企业，不必以牺牲质量为代价、来换取交付效率。这是因为，通过提升交付效率、效率和质量可以兼得。效率提升，本质是生产力的进步、是实打实的硬发展。而生产力进步，为更先进的质量运营提供了技术基础，甚至生产力本身就是更先进的质量运营范式。
所以我们经常能看到，以效率提升为目标的建设工作，往往出人意料的促成了质量飞跃，反之则不然。技术发展才是硬道理，运营次之。
更进一步讲，效率先于运营。效率代表了生产力、是技术发展的根本动力，决定了运营的高度；质量、成本、安全本质都是运营(守成)，无法催生技术革命。
2023.05.05 产品要花时间打磨
产品不会一蹴而就、而是要花时间打磨。1对夫妻，10个月可以生1个孩子；10对夫妻，1个月生不出1个孩子。
2023.04.07 中台的定义
技术中台，本质是功能复用，避免重复造轮子。中台的聚集形态，为规范、流程、架构、业务等提供了理想的管控场所。
2023.02.23 架构抽象的方法
架构的核心是管理复杂度，核心能力是抽象能力。抽象有二种套路：
- 第一、通过归纳法找共性。从多个问题中找共性，提炼通用解决方案；方案是不完全解、可能不普适
- 第二、通过演绎法找关系。从多个问题中找关系、推导假设，让后将这个假设应用于其它问题；假设不对、则后续全错
归纳、演绎，说时容易做时难。
2022.11.29 监控产品的选型思路
服务监控的能力构成，80%来自属主维护的权威知识，20%来自客户的自助分析。
站在产品选型角度，好的监控产品，不仅仅要足够灵活(自助分析)，更要有利于维护(权威知识)。
站在服务治理角度，权威知识不足、自助分析占比过高，预示着服务管理体系不完善；长期持续，则意味着建设思路出了问题、纵向不闭环。
2023.08.08 观测处于技术体系下游，应尽量复用上游的标准、规范、权威体系，降低建设和运营难度。关键是数据质量、场景抽象。
2022.11.19 数据处理要接受人工
人工处理短期干不掉，因为数据计算模型多变、无法固化为代码。人工处理常见形式，有Excel计算录入、SQL调数等。
具体分析如下。数据处理器，有固化代码、人工实现两种方式，主要取决于数据生产是否确定。数据生产由计算模型、元数据决定，包括数据生成、预处理、清洗等。根据数据生产是否确定，数据处理器可以遵循如下选型规范：
- 计算模型、元数据都确定：处理器是固化代码、触发频率固定，表现为定时任务、常在服务。如天级成本计费
- 计算模型确定、元数据多变：元数据先要配置化，之后，处理器是固化代码、触发频率按需，有定时触发、API或UI按钮人工触发。如月度成本分摊
- 计算模型多变：处理器由人工实现，常见形式有 Excel计算后再录入、SQL调数等。如年度预算提报
现阶段人工处理还干不掉。对于计算模型多变的数据处理器，需要格外关注知识传承。
2022.08.23 五段式运营建模法
五段式运营建模法，包括「模型、指标、目标、路径、组织」，在特定领域下、适合构建全新的运营模型，已经在成本优化场景中证实。
经典归纳法之「质量、效率、成本、安全」，试图以画框填空的方式、辅助横向查漏补缺，但并不适合纵向梳理。生命周期归纳法，非常适合纵向梳理，待体系化产出。
2022.08.16 同环比释义
环比、同比用于描述统计数据的变化情况，两者经常因为 不同语境预设的统计周期 而混淆。
环比表示本次统计周期与上个统计周期的比较，是两个完整统计周期之间的比较。比如，2010年中国第一季度GDP为G100亿元、第二季度为G102亿元，则第二季度GDP环比增长 (G102-G100)/G100=2%，这里的统计周期是一个季度。
同比表示本周期与上个周期的某个统计片段的比较，是两个统计片段之间的比较。比如，2010年中国第一季度GDP为G100亿元、2009年第一季度为G80亿元，则2010年第一季度的GDP同比增长率为 (G100-G80)/G80=25%，这里的统计周期是一年、片段是第一个季度。
类似2010.10、2010.08这两个月的比较，中英文都没有对应的专有名字。之前通常叫做环比、因为这是两个以月为周期的比较，现在看称作”10月环比08月”更合适。时代发展太快，语言演化偶尔都跟不上节奏了，何其幸哉、何其悲哉。
2022.08.11 滴滴闭门会的思考
今天参加了滴滴运维闭门会，记录当时的几个输入。这些输入，最后都应该被归纳到对应的主题。
- 平台：可观测的瓶颈已经从平台能力、转移到数据标准化，归根结底还是标准化（点评：观测的难点在数据质量、场景抽象，不在观测平台自身）
- 平台：放火平台目标是，构建风险可控、可重复执行的场景验证能力，验证内容主要是服务架构、运维管控的完备性（点评：防火属于逆向工程、代价高）
- 平台：KubeVela本质是声明式的交付编排，支持研发、运维视角的关注点分离OAM
2022.07.21 尊重大势
任何成就都依赖大势，要借势(选择合适的时机)、不逆势(不在错误的时机做事)。
技术项目的成功，除了组织给力、人才足够、技术具备等因素外，公司大势是第一要素。比如，我司多云+云原生能够高质量落地，依赖高效的组织、经验丰富的人才、成熟的社区技术，但首先是「国家监管情况下的 业务增长骤减、存量还能维持」、这为技术升级提供了宝贵的时间窗。
技术发明、人生际遇也都是如此。大势面前，所有其它因素都是技术性的。
2022.07.15 数字孪生的一些理解
数字孪生(Digital Twin)，本质是：把物理对象建模、搬到数字空间做分析，并把分析结果、作用回物理对象。关键点包括领域建模、指标采样、挖掘分析、结果应用等，如下图。其中，领域建模(含指标设计)，是知识不断迭代的过程、不会一蹴而就；建模完成后，才会进行指标采集，两者逻辑上是先后关系。
和数字孪生相关的概念，还有计算机辅助工程CAE(Computer Aided Engineering)。
2023.08.09 数据孪生的终态，很可能是镜像世界，即在数字世界中、重建人类文明。
2022.07.14 顺丰数据中台的启示
顺丰数据治理体系的理念，包括：一套治理体系、一个数据中台、N个应用。要践行这样的理念，首先需要管理层共识，支持推下去；其次，平台要足够简单透明，让用户愿意配合；最后，要有配套的数据运营，需要有一条准绳、确保标准规范得以落地，并让数据的价值得以数字化显现。
顺丰在实际业务场景落地时，最大的困难在于内部推动，需要管理层自上而下推动。因为，数据共享、多人协同、数据标准化都是需要跨组织拉通，并推动对现有的内容进行改造的。从结果看，顺丰的数据中台能够顺利推进，最大的因素是管理层下定决心、坚决落实。反观，技术能解决的问题都不算是大问题。
顺丰数据中台的建设过程，很像我司的多云建设。强权的技术组织、自上而下的推动方式、统一的治理方案、重视标准化运营，这些也是我司多云能够成功的关键点。
2022.06.30 认知代差会招致降维打击
认知不够，努力也白凑。认知代差，会让你错失自我革新机遇、逐渐变的落后，最终招致降维打击。
比如，大清朝自诩天朝上国、宗藩中心，没有意识到世界新形势，招致帝国列强的轮番撕咬、险些亡族灭种；之后虽有变法维新、洋务运动，但都没有触及精神内核；直到吸收转化了新民主义、共产主义，中华民族才得以重返世界之林。
再比如，我大运维团队，前半程固守老旧经验、错失了云原生的先机，差一点被打到魂飞魄散；之后我们努力补课、自我革新、吸收转化新理念，持续两年多、才实现了赶超。
认知不够、努力也白凑；能力的提升，首先要从认知开始。这是多么痛彻的领悟啊!
2022.06.24 标准化是批量管理的前提
技术对象的标准化，让运维批量管理成为可能。举个配置监控大盘的栗子，
之前，监控数据不标准、各业务乱打，配置大盘时只能填写完整的指标键值对。为了实现批量管理，很多公司会搞一个指标管理系统、人工维持打标分类（大数据BI平台的标配），然后再根据这个系统、生成监控指标配置、填回到监控系统 —— 在展示层做指标配管固然能解决问题，但处于链路末端的配管 不免重复建设、运营成本高，很容易走向裂变。
反观，服务治理完成后，大部分监控数据由资源、组件、框架、系统自动生成，而且受控于服务提供方；监控数据的指标名、管理标签高度统一，监控数据本身就能很好的自说明。运维也会做一个配管，在数据生产后、入库前补全上管理标签。此时，配置大盘就可以使用Repeat选项、批量生成，后期运营也几乎是零投入 —— 前置的 规范+权威服务，最大程度的规范了数据生产，在源头上避免了数据裂变。
上面是数据治理的例子。这个例子也说明，标准化的生成要在生命周期的起点，而不是中间、末端。题外话，监控产品的难点不在产品本身、而在客户数据的标准化，监控SaaS厂商除了卖产品、可能也要同步兜治理理解决方案。
2023.08.16 标准化服务于规模效应，目的是降低规模化管理的成本
2022.06.21 问题驱动从来就不是问题，机械的思考和行为方式才是问题
因为X，经常把「问题驱动」当做形而下的末流、并深以为耻；而真实的工作中，50%+的技术进步又来源于问题驱动，理念和实践有巨大差异。这是为什么呢？
实践是真实发生、持续验证的，大概率是没问题的，问题只能出在理念上。我们对「问题驱动」的理解，到底有什么不对呢？经常被一起提及的还有「规划驱动」，尝试通过几个维度来对比下（问题驱动 vs 规划驱动），
- 灵感来源：当下遇到的问题 vs 当下遇到的问题 + 历史上总结的经验
- 决策过程：简单粗暴的拍板 vs 深度思考、充分论证，伴随着认知提升
- 对象范围：头疼医头脚疼医脚 vs 合理的时空延展
- 解决方案：机械的修复，补丁之上打补丁 vs 全局性、前瞻性的解决方案 + 可迭代的实现路径
从这几个角度分析，问题驱动、规划驱动的灵感来源是相近的(经验也大多源于问题)，主要差异在决策过程、对象范围。可以大胆假设下，问题驱动这四个字、最初只用于描述灵感来源，但在实践中逐渐被用于指代那些机械的思考和行为方式，「问题驱动」这个词被用烂了。
这样看，问题驱动从来就不是问题，机械的思考和行为方式才是问题。更高一级的目标驱动，也是以问题、需求为灵感来源的，是高水平认知在低纬度的投影，这个能力需要逐渐积累（梦想驱动也大多源自问题吧）。
2022.06.09 关于创造性工作的思考
①创新不是灵感突现，而是耐心地从失败中观察、改进(詹姆斯·戴森)。
今天听《发明》一书，是戴森公司创始人詹姆斯的自传，其中介绍了技术创新的方法。大体如下：
人们常常以为，发明的关键是灵感。戴森公司创始人詹姆斯认为这是一个误解，他以自己的经历告诉年轻人：发明更加看重的，不是灵感、而是一个人的耐力，看他能不能耐心地从失败中观察、改进。
绝大部分时候，创新不是灵感突现，而是耐心地从失败中观察、改进，是对专业的持续改进、是微创新的集腋成裘。我个人感受的创新路径是：「实践 -> 深度思考 -> 改进 -> 实践」，这个路径持续循环，其中 深度思考是创新发生的关键点。
②创造性工作要找准边界，在边界内做事情。
好的发明人要在时代的边界内做事情，好的工程师要在公司的边界内做事情，好的架构师要「在公司的边界内落地新技术」、而不是空谈误国。这些思考，来自「得到-硅谷来信2·谷歌方法论-计算机从简单到复杂」。精简信息如下：
巴贝奇(滑翔机之父)的悲剧在于他的想法太超前，以至于当时的工业基础无法满足他的设计要求(自带动力的飞机)。 从这个意义上讲，巴贝奇更多地是科学家，而不是工程师。我在《见识》一书中介绍了前苏联设计和制造“米格25”战斗机的成功经验，从那个案例中可以看出好的工程师是如何在边界之内做事情的。
③创造性工作有运气成分。
科学技术领域的成就，依赖时代赋予的大势；工程领域的成功，也要等到风云汇聚、各种条件都成熟，俗称运气成分。比如我们云原生架构团队，其成功的关键，既有自身经验和努力、也有运气成分，他们来我帮足够早、以至于云原生还没启动，他们来我帮也足够晚、以至于K8S社区和公有云都已经做好了准备。
上述思考，来自「得到-硅谷来信2·谷歌方法论-发明背后的逻辑」。精简信息如下：
成功的发明要等到风云汇聚，各种条件都成熟。莱特兄弟成功的关键，既有自身科学的方法和努力，也有运气成分：莱特兄弟出生得足够早，以至于飞机还没有被发明；他们出生得也足够晚，以至于凯利的理论和奥托的内燃机都已经为他们准备好了。
④跨领域迁移有助于创新。跨领域不单是创新型应用，更多是理念、模型，如信息论对运维领域的熵增启示。
⑤借鉴他人有助于创新。借鉴有助于提高创新效率，但必须要坚持彻底吸收、融为几身。
2022.04.22 微服务化治理的挑战
微服务是一种软件架构、组织方式，通过将大型的服务、拆解成独立组件，来解耦人员和应用的生命周期。
在云原生的大潮下，微服务架构在应用层全面达成，并且按照应用视角、完成了资源(容器技术)和组件(网关代理)的部分服务化。但我们也能看到，当前依然有很多对象，无法像服务端的应用一样、按功能拆分成微服务，也无法低成本的迁徙改造。比如：
- 数据：数据库，大数据离线、实时服务，对象存储桶、共享文件存储
- 组件：接入网关，服务化框架，服务域名，消息队列集群
- 资源：网络地址、安全域，未容器化的虚机
- 客户端：历史版本
在当前的技术发展阶段，微服务的组织方式有局限，无法用于管理数据、组件、资源、客户端等对象。这可以作为运维管理的技术边界。想要以微服务化的视角管理所有对象，就要找到合适的技术方案，避免人肉运维。
2023.08.16 从运维管理角度看，集群是资源、组件、应用的通用单位，微服务中的模块集群即为集群。
2022.04.15 重复造轮子是否合理？
重复造轮子是否合理，可以分几个维度看：
- 公司角度看，以个人牟利为出发点的轮子绝对不正确。资本家视角，但没啥毛病
- 行业角度看，具备成本优势的轮子可以重复造。有助于优化行业结构
- 国家角度看，具备安全考虑的轮子值得造。如中国卡脖子攻关
技术角度看，重复造轮子难有结论。因为目标、度量标准都不唯一，正如”文无第一”。
2021.12.29 架构选型的关键点
架构选型要做好长短期利益的权衡，放弃短期最优解、采用次优解，来平衡短期和长期的利益。
架构选型要客观思考、避免个人偏执，尽量避免手里有锤子、一切问题都是砸钉子的事情发生。
架构师的价值，不在于创新，而在于为公司选择一条稳妥的、合适的路，不求原创、但求合适。
具体的，
- 做好长短期利益的权衡
- 问题：架构选型时，一般会面对 1、短期的痛点，2、中期的瓶颈，3、长期的先进性。技术经常面临的问题是，长期容易被低估、短期又会被高估
- 原因：究其原因，人类的天性就是容易看到眼前的问题和痛点，在思考问题时也会从眼前的问题着眼入手出发。这本身是无可厚非的，也是符合客观规律的。毕竟，「先活下来」永远是思考的第一要素。
- 解法：但是对于资深的架构师来说，技术选型中短期的利益往往是会和中长期的收益存在着或多或少的矛盾和取舍。这就要求，有时候要放弃短期的最优解，采用次优解，来平衡短期和长期的利益
- 评价：架构选型要兼顾短、中、长三期解决方案，给出合理的过渡方案，不考虑现状的rearch都是空谈
- 客观思考、避免个人偏执
- 问题：每一位架构师其实都有一些自己的偏好，有一些自己的执念。
- 解法：从实际问题出发，避免个人的经历、偏好、执念对技术选型的影响。在做技术选型时，能时刻警醒自己，跳出来，从一个相对客观的角度，从问题域出发去评估整体选型，而不是从具体的手段、方法来看待问题，尽量避免手里有锤子，一切问题都是砸钉子的事情发生。
- 举例：当然，这也是一个知易行难的事情。我个人的一个具体实践是，在做技术选型和设计时，即使未来是要自己去落地，也不会把自己代入未来的执行层面或者实施层面去思考细节。当然，如果设计和落地本身是分离的，就没这个烦恼了。但是，大多数时候架构师是没机会真正置身事外的做一个「顾问」的。
2021.11.27 面向过程和面向终态的对比
面向过程、面向终态是两种自动化系统建设思路，两者建设目标不同；目标差异又延伸到了交互形态、技术路径、运营成本、适用场景等多方面。大体如下：
- 面向过程
- 建设目标：操作结束后的瞬时、系统达成特定状态，不关注之后状态。面向过程又叫面向瞬态、面向操作。
- 交互形态：命令行、工作流
- 技术路径：使用工作流、编排原子操作，实现复杂的业务逻辑；顺序上，先有原子、后有编排，原子、编排两拨人做，组织结构解耦
- 运营成本：短平快，前期能复用经典工作流等能力，后期运营成本高(额外投入运营力量、维持状态，IT系统规模越大需要的投入越多，熵增效应显著)
- 适用场景：资源交付等高风险场景，如机器购买、域名变更
- 面向终态
- 建设目标：通过自动纠偏等方式，将系统长期维持在特定状态
- 交互形态：配置定义，如K8S声明
- 技术路径：需要强大的解析引擎、控制器、实时观察能力，实现复杂的业务效果；顺序上，先有业务模型、后做原子能力，组织结构更紧密
- 运营成本：前期建设难度高、开发投入大，后期运营成本低、熵增问题少
- 适用场景：应用管理等自动化风险相对可控的场景，如实例弹性扩缩、配置发布
两种建设思路不能代表技术优劣，如工作流经常用于面向过程、但也可以做成面向终态；技术只是实现目标的手段、并无高下之分。回到运维领域，运维建设目标既有瞬时交付、也有终态维持，两种思路都能用得上。
2023.08.17 面向终态可以作为管理建设的最终目标，但不应该是中短期目标。面向终态的前提条件是风控能力，主要体现在稳定性、成本、合规方面，前置风控能力建设投入大、打磨要花时间。
2021.05.16 云原生的简单认识
云原生是一套开放的基础设施建设标准。基本上，向下抽象IaaS、中间约定PaaS建设规范、对上呈现应用接口。
K8S是云原生标准的一套开源实现方案。K8S的理论基础脱胎于谷歌Borg，在IaaS资源抽象、PaaS托管规范方面做的不错，向上的应用接口还在进一步优化中。
K8S不等于云原生。符合标准的公有云、私有云、混合云方案，均可认为是云原生。
详情可以参考： 云原生之架构思考
2021.04.01 美团技术发展的跟跑策略
技术建设要比业务需求快一步、比业界先进慢一步，要在思考深度、技术体系性上做到业界最牛。
这是美团的跟跑策略，在技术方向的体现。略有参考价值。
2020.09.25 元数据运营的关键点
好的元数据运营体系，应该具备这些特征：强依赖、可复用、可校验、可收敛
- 强依赖，至少被1个关键的管理路径依赖；
- PS：如果被服务调用链路依赖，那非常不幸，因为元数据改动很慢、长期无法收敛
- 可复用，能被2+个场景使用、实现价值扩展；
- 可校验，在现有元数据体系中，能交叉互验数据的正确性，降低修复更新成本；
- 可收敛，生成和维护成本可以逐渐降低，数据质量可以逐渐提升、最好是自动提升
强依赖、可复用、可校验，很大程度上都是在推动可收敛。是否有利于元数据的收敛，是判断一个运营方案好坏的重要指标。如，
- CD审批，上线审批权限点是一个差方案、因为审批权限生成过程收敛成本高
- 服务负责人审批是一个好方案，因为服务负责人是一个可以被精心维护的元数据
说的再激烈一点，元数据不收敛、罪一定在平台(的运营方案设计)。
元数据运营，应遵循如下分工：
- 谁交付、谁生产。服务提供方主R功能交付，是元数据生产者；生产行为通常有交付平台实现
- 谁生产、谁管理。服务提供方是元数据管理者，有责任运营好元数据质量，『管生也要管养』
- 消费者不承担管理职责。合法的消费者有权享受符合SLO的元数据、而不需要付出管理成本
运维->基础设施(20230911)
2024.08.23 技术安全之过
在大部分公司，技术安全都是负向生产力。为什么呢？除了刚性的隐私合规外，技术安全团队在以下几个方面可以做的更好：
- 目标正义性：提前协同目标，避免争抢资源。设计不佳的安全目标，不但无法贡献于业务目标，反而会争抢人力资源，变成负向生产力。
- 权利正当性：打破专业封闭，拥抱分权监督。安全专家倾向于单向建设，制定标准(立)、发号施令(执)、审判结果(司)，成为三权独揽的独裁机构。
- 为了攫取正当性，催动认知偏差、混淆概念、威逼恐吓，更加招致反感。
除隐私合规外，技术安全团队的价值呈现很尴尬，既有横向协作的使命(通过别人拿结果)、又要操管理者的心(背负安全指标)，左右为难。
要想维持强势作为，则需要自上而下设计目标、明确授权，合法合规的调度业务研发资源。也可借鉴OPaS模式，组织职能由横转纵，安全团队聚焦安全能力建设、推动业务安全自闭环。
2023.11.07 通用和定制之争
在基础设施领域，功能、工具的建设多少会有通用和定制之争。尝试通过多维对比的方式，呈现两者的差异：
通用(General) vs 定制(Special)
- 能力粒度：原子 vs 组合（是否存在能力组合）
- 需求视角：服务提供方 vs 服务使用方
- 产品形态：烟囱式 vs 场景化（产品形态是需求视角的延续）
- 功能体验：难用 vs 好用（是否需要使用方自己做功能编排）
- 经济价值：高ROI vs 低ROI
基础设施选择通用还是定制，主要取决于ROI(即投入产出比)。通用意味着高ROI，因为无论如何你都要用到原子能力，基本可以无脑决策。定制的ROI则由场景决定，重要场景的定制才具备经济价值。对ToB领域而言，找准高净值场景、打造定制化产品，是非常不错的选择。
2023.09.10 应用技术的价值
应用技术是成本中心，其本职是支撑业务、实现盈利，这是由商业组织的本质决定的。应用技术本身不构成任何独立价值。
技术中台，是应用技术的治理组织，目的是提升应用技术的长短期ROI。中台可以服务化、自动化甚至智能化，但其本身并不构成商业价值，甚至重要性不及应用技术。
时也势也，命也运也，此之谓也(出自<吕蒙正格言>)。只有互联网退潮时，才知道谁在裸泳，何其悲哉! 程序员、专家、架构师之流，再也没有牛逼轰轰的资本了。
以上观点，不包括ToB类信息系统服务公司。
2023.09.06 中台之殇
技术体系演进到一定程度后，中台的杠杆价值下降、仇恨值开始爆发，很多公司都在上演类似过程，为什们呢？
中台在很大程度上是管理工具，是阶段性产物。在技术体系的建设期，CXO可以借助中台，撬动业务技术组织的根深蒂固，贯彻新思路、推动新变革。在技术体系的成熟期，中台就失去了管理价值，很难再得到足够的资源、随技术组织一起扩张。
中台的管理属性和阶段性特点，决定了这样的事实：中台失去掌控力、并逐步走向瓦解，是技术组织发展的必然结果。
2023.03.19 技术中台的职责
技术中台提供软硬件基础设施，支撑业务研发、实现业务需求。
软硬件基础设施，首先要有的用，如功能建设、需求交付；其次要用的好，如服务规范、度量治理。相应的，技术中台追求规模效应下的质量、效率、成本、安全、可持续，服务和管理手段可以并用。功能建设、服务规范是服务手段，需求交付、度量治理是管理手段，随着技术进步、管理手段可能会逐步服务化。
技术中台、业务研发两个团队的交界面，当前还需要专业转化的角色、类似翻译员。业务运维(或运维BP)可以承担这个角色，业务研发的架构师或技术Leader也可。
2023.01.11 运营工作的物理模型
运营工作遵循熵增定律，即IT系统通过输入负熵、维持有序，缺少输入、则自发走向无序。负熵来源，可以是纯人力(手工)、算力辅助人力(机械化)、或纯算力(智能化)。
从熵增的角度看，信息化的过程也是负熵不断从人力、转移到算力的过程(固化智力)。算力比人力更具性价比，因此信息化也代表了更高的生产力水平。
2022.09.23 百度运维的架构师培养模式
首先，运维要保住业务价值。通常的方式是，运维承接运营Toils、换取RD的信任和依赖，如处理报警。这部分工作由低阶运维人员来做。
然后，在重要业务安排高阶。让高阶运维人员，伴随业务、成长为架构师。运维架构师，通常也具备一定的业务架构能力。
之后，轮岗、成熟的架构师转移到新兴业务，腾出原有业务、用于培养新一代架构师。
百度运维的培养模式，有利于产出高阶架构师、且长期可持续；受限于岗位容量(<10%)，成熟的架构师将不断出走，这也使得百度成为了运维界的黄埔军校。百度模式，过分强调运维的业务价值(依附性)、使得运维很难转型为纵向专业领域，这是弊端。
2022.09.08 谷歌SRE视角的应用生命周期
谷歌把服务生命周期划分为五个阶段。它认为，从Idea确定那一刻应用就诞生了，然后进行架构设计，接着进行开发，再灰度/全量放量，最后到该服务弃用，终结生命。如下图。
上述内容引用自《SRE运维思考与实践》一文，作者是作业帮SRE负责人邓瑞龙。
2022.07.07 如何解读「运维的最终目的是服务业务」
「运维的最终目的是服务业务」，这个观点很模糊，看似是在表达目标、其实还在暗示方式。有必要好好分析下：
首先，任何技术岗位的存在价值，都是为了达成业务目标、为公司开源节流，运维岗位亦是如此。这是政治正确，不存在任何异议。
其次，服务业务的方式有很多种。你可以融入业务前线、成为业务的一分子(Tobe)，可以紧贴业务、提供保姆式护航(Sidecar)，也可以强化分工、用专业能力服务好业务(SLO)。从人类社会的发展路径看，专业分工的方式可能会走得更远。
So，目标、方式要分开看，没有谁是政治不正确，只是采取的方式不同、而已。
2022.07.02 如何看待监控(monitoring)和可观测(observability)
可观测是一个服务治理的概念，鼓励应用以标准方式、充分暴露自己的状态，以便于从外部做应用诊断，这个过程很像数字孪生中的对象数字化。我所理解的监控，是构建在状态数据之上的、全局视角的产品功能，属于应用诊断的范畴。So，监控、可观测不是同一个维度的东西，监控是base在可观测之上的。
以下是之前的分析，错把可观测当做应用诊断的产品功能来对待了，不过也有参考意义、保留下来。
- 业务场景：监控用于稳定性管理，典型功能是故障报警、全局定位Scope；可观测用于质量管理，典型功能是链路分析、应用分析Apm，从外部的数据特征、推断应用的内部状态（数字孪生）
- 目标用户：监控对运维、研发TL等有全局视角的工种比较友好，可观测对研发RD更友好
- 平台功能：监控以Metric为基础，主要功能是故障报警、时序报表；可观测覆盖了Metric指标，同时还囊括了Logging、Tracing、Event等APM能力。监控是可观测的子集
- 技术手段：监控专注于时序数据分析；可观测更强调关系数据挖掘，更像是应用领域的实时大数据BI
2022.01.09 代码是工具知识的最佳载体
最近看HashiCorp联创采访，其对工具输入的理解挺有意思: Knowledge should be represented as Code，典型代表就是IaC。
工具的输入方式，先后有Env、Config、命令行、API接口、UI、Code等形式。Code方式在「知识沉淀+传播」上有优势，受到了创投界追捧。
2022.01.09 开源的价值在于形成事实标准
利用开源、形成事实标准，是企业最牢固的隐形护城河。开源社区的用户，都是你潜在的客户，他们有付费需求时会优先考虑到你。一旦你成为了事实标准，社区用户即使没有付费也是你的护城河，因为他们一旦有付费的需要，你的产品肯定是在优先考虑位置上。这极大挤压竞争对手的空间，这里的竞争对手甚至包括将自研产品开源出来的科技大厂 —— 科技大厂不是目标付费客户，但是他们内部使用开源产品替代自研产品，实在太普遍了。
工具类产品比拼的不是单纯的性能，更是工具背后的、代表新生产方式的方法论。把最佳实践抽象成方法论，才是真正的企业护城河。
以上内容，引用自「HashiCorp联创采访纪要」。
2022.01.03 中国的运维领域缺少体系产出
中国的互联网运维领域为什么缺少体系产出，如ITIL、Devops、K8S等？相比而言，中国运维领域的分工偏重运营，这带来了很多问题。如：
- 资源投入不足，国内大环境重业务、轻运营，运维拿不到足够的优质资源、做长做深。这是中国互联网基础设施的通病，不限于运维领域
- 专业深度不够，受困于运营的定位，运维工作者缺少软件工程思维、不知道如何深挖，虽然运维的场景足够广。运维只能附庸业务、寻求安逸，价值越做越薄，大部分老兵会在10年内转行，这又加剧了人才不足
- 技术革新滞后，运营属性决定了运维成为应用学科、而不是基础学科(基础设施方向)，运维处在技术的最外延、很难自我革新，历次技术革命都依赖外部输入
运维领域想要体系产出，可能要分出一部分人：在充分了解运维场景之后，吸收软件工程知识、养成基础学科意识，在一个更高的维度完成对运维工作的系统化抽象。这部分人就是运维架构or运维中台。康威定律再次发挥了它的指导意义。
2021.12.29 中国不需要照搬AWS模式
今天听到一个有意思的说法，个人比较认同，如下：
“AWS之所以成为现在的AWS，核心是老美的甲方有一帮足够短视且极度利己的职业经理人，以及他们所处的商业环境。 我个人认为中国不需要AWS，中国需要的是稳定且可靠的基础服务，或许它是分散的、或许它的社会效率不算最高，除非是打算出海赚钱、和AWS抢市场”
公有云虽然被认为是基础设施，但基础设施不单纯是技术、更多的是业务场景，基础设施本身就是业务场景。技术可以通用，业务场景可以遵循中国特色，窃以为「中国不需要照搬AWS」。
2021.12.01 IT职能是否会聚集到头部SaaS厂商
圈里前辈安利一篇文章，核心观点是 “IT部门的职能会聚集到特定SaaS厂商”。
从经济发展的历史看，分工会逐渐聚集到少数寡头，这个结论成立的前提是: 产品或服务足够的简单标准化、需求足够平或有第三者负责抹平。”IT部门的职能会聚集到特定SaaS厂商”，依赖SaaS产品的足够标准，依赖IT需求高度标准化，IT个性化需求可能很难被优雅满足、此时就需要一个薄薄的IT部门来抹平。
最近圈里突然有太多的SaaS/PaaS热捧。对创业者来说，炒热一个方向、把自己放到头部固然没错。但也请留下口德，忽略现实、一味鼓吹会带骗很多后来人。
20220711按：上述观点之争，就是「甲方追求实用、创投追求先进」的一个典型，两者是站在不同的时代、思考同一个问题。放眼将来，大部分IT职能会聚集到头部SaaS厂商，IT服务会变的高度标准化、个性化会被模块化组件抹平，IT部门也将随之弱化
2021.11.30 向后兼容是新版对旧版的兼容
昨天讨论RocketMQ管理平台设计，要求兼容老版本的产品特征，顺便整理了下”向前兼容”、”向后兼容”的概念。
- 向后兼容，是新版对旧版的兼容，对应的英文是 backward compatibility 或 downward compatibility
- 向前兼容，是旧版对新版的兼容，对应的英文是 forward compatibility 或 upward compatibility
我们一般会认为向前兼容是向之前的版本兼容，这个理解其实是错误的。
细细分析，类似前后这样的方向词汇，是以人个体为参照系的、有一定的主观性。汉语中，”向前看、这之前、前人、后人”的同字逆反表意，加重了混淆，导致: 以个人主观为参照系、解读出的含义，跟时间参照系得出的结论完全相反。同样的现象，还发生在对”左右”上。
2021.11.24 平台建设的可选路径
昨天和两位SaaS老兵互撕，对平台的建设路径有了量化认识。平台建设可以采用开源+二开、外采、自建三种途径，对比如下：
不同国度、不同公司、不同阶段、不同领域，功能、体验、数据、成本的权重会有所变化，开源、外采、自建的得分也不尽相同，按需调整。
2021.10.31 AIOps是ToB生意、不适合自建
AIOps技术体系，由运维数仓、AI框架、AI平台、运维场景组成，要求具备理论基础、人才密度、场景精度、业务深度等。需要注意的是，软件的一些”算法逻辑”不代表真正的AI，AI的关键点在于：自动从数据学习中总结规律、并利用规律给予决策建议。
AIOps不适合自建。前期要求高投入、后续无法持续产出，ROI太低。AIOps能力体系前期需要集中的高投入；即使解决了前期的高投入问题，受限于公司体量、自建AIOps的产出效果很快就会遇到天花板、不会持续增大。加之，AIOps落地的产品太少、未兑现AI效果，人心早已疲软。
AIOps更适合ToB。在持续高投入的要求下，只有把整个运维领域当做市场、有足够的收入来源，AIOps才能ROI转正，才有可能持续投入、持续产出（资本密集型）。AIOps这门生意逐步集中到少数SaaS厂商，大部分公司从自建、改为外采，这可能是最终形态。
之前的几年，AIOps的概念被过度炒作，大大小小的公司都尝试自建、结果碰了一鼻子灰，甚至整个中国运维领域都被带偏了。带节奏也要负责任!
2021.09.30 运维流程的优化方式(思考尚未成熟)
运维流程的优化方式，可以从提升流程效率(效率)、加强运营力度(质量)、改善完整性(功能完整性)、加强可视化(功能易用性) 这四个角度进行。
- 提升流程效率。缩短流程、减少人工、或加强人的能力，具体手段包括：缩减流程，流程自动化，提供流程决策所需的辅助工具(如根因定位)，历史流程回溯复盘找到瓶颈点，等
- 加强运营力度。事前把关(准入)，事后运营(复盘)
- 改善完整性。横向打通组织协作，纵向串联场景工具，兼顾商务、财务、运营等环节
- 加强可视化。流程可视化，促进企业运维活动透明、信息共享，提升效率与体验；进一步就是度量
特别的，流程的运营，需要基于量化指标持续反馈、螺旋式进化。
2021.09.30 集约化是IT运维的最佳组织结构
互联网IT运维，从手工运维，逐步发展出了标准化、自动化、运维和研发融合的DevOps等阶段。
对应的，运维管理也逐渐实现了集约化，包括组织集中化、资源集中化、数据集中化、平台一体化；管理平台的进化，是从最初的文档、脚本，发展到烟囱式、服务目录，再到场景闭环。
在当前的技术、组织、人文条件下，集约化是企业降本增效的必然选择。
20220712按：组织、资源、数据的集约化，为运维管理做好了组织准备。之后，需要将运维能力服务化OPaS，运维通过平台、和上下游业务相互依赖，这是技术目标。
2021.09.29 SaaS和企业数字化转型的几个观点
SaaS经济的本质是市场角度的「长尾边际效益递增」、金融角度的「数字化分期付款」。对应的，SaaS产业的根本性问题是如何提高复购、续费率。
SaaS产业过去和现在的商业本质是资本和产品，未来的商业本质必将是用户体验。SaaS厂商要做到极致的用户体验。用户体验的终极形态应该是自私的究极体现——我感受不到你的存在，但我需要的时候，你的服务总是那么恰到好处，深得我心。
数字化转型的本质是赋予业务以数据，用户体验则是赋予数据以人性；洞察数据、赢得市场，洞悉人性、赢得一切。
参考：原文
2021.08.10 运维面
在微服务生命周期管理中，运维人员需要符合运维视角的运维面、即运维管理平台。
微服务架构中，一般会抽象出控制面(control plane)、数据面(data plane)，方便架构管理。今天，听头条Mesh分享，明确提出了运维面(op plane)，眼前一亮。
之前，总是感觉架构提供的管理平台非常难用，不符合运维习惯，但找不到具体原因。现在回想起来，架构视角的管理平台更多的是控制面、是架构能力的延伸，运维人员需要符合运维视角的运维面、即运维管理平台。
20210713按：运维面(ToM)沉淀了适量流程规范，是全局视角的操作习惯；再往上还有用户面(ToC)，结合了严格流程规范，是适合RD的应用视角。
2020.11.17 警惕工作中的代偿效应
警惕工作中的代偿效应，避免补位现象长期持续。
被安全后SYS再次应急强上，不专业的人补位专业岗位，像极了医学上的代偿效应。什么是代偿效应？代偿效应指的是用临时方案、替代弥补掩盖原方案的不足，短期能达成预定效果、长期会留下永久伤害。举一个例子、来证明它的危害：
很多慢性病病人，在早期的时候没有任何症状，看上去非常健康，自我感觉也良好。但是一旦出现症状，一查，就已经是中晚期了。这些病人就很奇怪啊，我明明一直好好的，怎么突然就病得这么重了？很多情况下，这就是代偿导致的。比如说胃癌。现代医学已经发现，胃癌和一种细菌有很大的关系，这种细菌叫做幽门螺旋杆菌。这种细菌一旦感染了胃部，就会持续攻击胃部的细胞，导致胃部细胞的死亡，引起胃炎，最严重的就是胃癌。那最治本的解决方案是啥？当然是消灭这些幽门螺旋杆菌。但是如果我们身体自带的免疫系统做不到，它就会启动一个替代方案，就是让深层的胃部干细胞加速分裂，赶紧补充死亡的细胞。这是啥？这就是代偿啊。这是一个临时性的、替代性的解决方案。那在我们人体的感觉中呢？胃的功能正常进行，啥感觉没有。但是，在你没感觉的同时，这场细菌和胃部细胞的战争其实是越打越激烈的。最后，当人开始有感觉的时候，说明就是代偿功能已经补不上细菌造成的损伤了，这场战争等发现的时候，就真的危险了。
完整文章，参见这里。
2020.08.14 规范落地依赖中心权威
规范有大小。大规范一般画出一个轮廓，能给出指导意义；具体落地则需要SRE的个人来执行(小规范)。
SRE个体习惯有差异，对小规范认知不一致，最后可能伤害到大规范的落地效果。这就像开发团队的代码风格治理一样，在小规范实施时，要有机制、拉平SRE的习惯认知（事实证明 个体自觉不靠谱）。
20220713按：规范落地 要依赖强大的中心权威，寄希望于个体自觉是非常不靠谱的。对于外延规范，中心权威能被平台替代；对于元数据，中心权威不可替代。
2020.04.15 平台是最好的协作者
平台是运维最佳实践的有效载体，最终都能进化为用户友好的形态。 从这个意义上讲，平台可以协助降低对从业人员的服务心态要求。在工具达到一定能力之前，所谓的服务心态很难维系。
2019.03.22 业务运维的宿命思考
业务运维的具体工作，通常涉及两个领域：运维、业务。
业务运维的组织形式，一般有两种选择：统一的大业务运维团队、业务运维打散到业务线，前者如谷歌，后者如2018年的阿里集团。也存在第三种过渡性态：保留最小业务运维团队、同时业务线出人承担大部分运维工作，如2018年的滴滴。
不同的组织形式，是在运维专业性和业务人效上做折中。统一的大业务运维团队，有利于运维领域的专业性养成；业务运维打散到业务线，会最大限度的降低运维和业务的隔阂(如沟通成本、学习成本等)；过渡形态，如果落地效果好，既能保留运维领域的专业性、又能提升公司业务在运维环节的人效。组织形式的选型，本质上是挑选一种更高人效的组织形态，跟公司规模、业务形态、历史沿袭、团队喜好等有很大关系。无论哪一种形式，真心投入的话，应该都能走得通。
对于大型的、平台化的互联网公司，运维能力是一种长期且核心的竞争力，业务运维打散到业务线会严重损害公司在运维领域的专业性，对公司长远发展极为不利，大概率会被摒弃掉。
2019.03.15 运维的套路与创新
经过20多年的发展，运维领域在常见事项的方式方法上已经形成了固定的、可依赖的套路。如，稳定性建设思路、运维效率体系思路、工具平台建设思路。特别的，一本《Google SRE》几乎涵盖了常见的运维最佳实践。
将套路落地是运维的首选。将”套路”运用好后整个运维工作可能就拿到80分了，剩下的20分需要运维工作者深入一线(弄清现状)、大开脑洞(得出创新)，将公司的琐碎需求抽象为通用解决方案。创新的程度，展示了运维团队自我突破、不断进取的能力。
长久深陷套路会阻碍创新。过分追求创新，又可能会损害运维本职，两者还是需要酌情权衡的。
2019.03.14 以实事求是的态度建设工具
根据公司自身情况来建设运维工具，这是实事求是的态度在运维领域的一个体现。
运维工具的建设，主要受到如下几个因素的影响：
- 公司规模，对应的是运维工作总量
- 业务现状，如业务有是否自运维能力、技术体系是否收敛、运维工具是否多团队共建等
- 用户习惯，对于有一定历史沿袭的公司，保持产品形态的延续性显得尤为重要
- 自身能力，公司在运维工具上的资源投入、团队的人员素质等很大程度上决定了工具平台的建设选型
- 创新环境，不必多说
对高大上的盲目崇拜是人之本能，工具本身也没有绝对的好与坏。满足公司发展和团队成长的诉求，需要根据实际情况做好折中。
2019.02.22 SRE补位思维
在轻量级的运维模式下，SRE对业务的了解一般停留在能够止损的程度，很多时候SRE是业务的一个外挂。
在这种形势下，SRE可以尝试收敛自己的职责，将主要精力投入到做成事的角度。这里的做成事，大部分时候指的是把业务稳定性做好。
做好稳定性工作量会比较大，一个被弱化的SRE团队很难以一己之力搞定全局。SRE可以考虑把自己打造成一个补位者：以做好业务稳定性为目标，适度出让利益，做好各项兜底。
- 明确目标：达成业务稳定性指标
- 确定关键：按照稳定性拼图，做好工作目标分解。如，组织建设、机制建设、规范建设、工具建设、RPC框架建设等子任务
- 不挑肥：对于已经被协作团队主导的事项，SRE转为协助者角色，必须时可出让利益。SRE主动提供必要的资源支持，并做好过程监督、结果监督
- 不怕瘦：对于无人问津的项目，SRE要勇敢的跳出来担当，做好兜底
补位思维，是做成事态度在SRE工作中的体现。
2019.02.19 工作中的服务者态度
工作的第一原则是，时刻为当前的或者将来的用户着想。比如，
- 站在继任者的角度写代码
- 站在用户的角度做产品
- 站在读者的角度写博客
现在没做好的是站在对方的角度来做人，这是下一步要进步的方向。感谢滴滴，给了我一种可行的工作原则。
管理
2024.05.29 三权分立
三权分立：3 BRANCHES Of GOVERNMENT。
- 立法：Legislative，Make laws。Senate参议院，House of Representatives众议院
- 行政：Executive，Carry out laws。President总统，Cabinet内阁
- 司法：Judicial，Evaluate laws。Supreme Court最高法院，监督、审判
2024.05.06 拒绝政治斗争
人生短暂，容不得浪费，特别是那些无聊的内耗。明代刘伯温《绝句》诗云：人生无百岁，百岁复如何；古今英雄士，各已归山河。
经历池鱼之殃，有两个小心得。①祸从口出，看破不说破是基本的职场操守。②隔墙有耳，君子慎独。
2024.01.10 性格和工作的匹配
管理者的一大职责是：根据工作特点，筛选性格匹配的候选人。匹配的性格，能让工作效果事半功倍，也让员工更有获得感。
比如，运营的基本要求是有耐心，FinOps子方向额外要求细心+数字敏感，治理方向额外要求原则性，等等。
2023.12.11 决策空间
技术细节就是决策空间。
对于主R团队而言，通过阐述部分技术事实，引导技术架构、向己方期望演进，保留了决策弹性。对于大团队TL而言，决策信息出现缺失，这就需要他练就一双火眼金睛、识别关键细节，从而做出有利于大团队的决策。
决策本质上是一场零和博弈，是上下争利的平衡点。太上，则自主创新被抑制；太下，则方向大计有失。通过组织的宏大建制，约束博弈的平衡点、保障企业利益不受损。
2023.10.18 太上忘情
太上忘情，因为无情、所以公平。
2023.08.18 分治
分治，是人类最伟大的组织发明。
分而治之，始终把问题控制在可求解的规模，求解能力由技术和组织水平决定。
2023.08.07 建设性冲突
团队需要一定程度的建设性冲突，否则就是死水微澜、没有活力。
建设性冲突，指的是：员工在做事细节上的争议，通常发生在工作目标、工作过程中。与建设性冲突相对应的、是失能性冲突，通常是人际层面的冲突。
建设性冲突和团队业务是一个正态关系。当冲突水平低的时候，组织缺少交互死水微澜、没有活力，业绩水平也就会低；而当冲突水平提高之后，团队组织被激活，业绩水平会随之升高；当冲突到达一定程度后，人际矛盾会变大、成员之间内耗增高，整个组织的合作效率会降低，业绩水平也会降低。如下图，
从冲突业绩曲线看，团队确实需要建设性冲突，不过要控制在一定程度、防止升级到人际矛盾。
2023.06.29 未过滤的信息
管理者要走动起来，要经常到一线串串门、获取「未过滤的信息」。
「走动型领导」，可以避免组织信息过滤、造成的决策失误。
2023.06.15 云中台的用户界面
阿里云、腾讯云的用户界面使用成本高，主要感受是：云厂商缺少强有力的、终结问题的用户界面(销售)，甲方不得不自己动手、理解和协调众多纵向产品(产研等)。用户界面受组织结构影响，云厂商考核产研部门ROI、势必会让销售举步维艰，为了解决或甩出问题、销售倾向将产研暴露给甲方，这就造成不好的体验。
公共云如此，内部云平台亦是如此。基础设施中台是公司的内部云厂商，产研RD是其客户，基础设施中台过分的追求纵深、做轻横向，就会让产研RD找不到用户界面、使用成本过高。这也是组织特点的延伸。很久之前，Ops承担了用户界面的角色，用人工服务的方式发挥短期价值，但因为缺少技术沉淀，领域不断被兄弟团队蚕食、路越走越窄；为了自救，Ops不得不脱横转纵、加强技术，近乎矫枉过正，结果是中台割裂成了众多纵向、没有角色为统一友好的用户界面负责。
用户界面非常有价值，我们有责任、有义务建设一个友好的用户界面，但也绝不应该重走人工服务的回头路。
2023.06.14 技术交互的关键卡位
技术交互的关键卡位，有入口、关键节点、出口三类。入口是技术视角的交互起点、流量入口，如ToRD界面、Ops支撑人员。关键节点是关键技术路径的汇聚处，类似网络交换设备，如变更管控中心、数据管理中心。出口是给最终用户交付的场所，通常横跨多个领域，有潜力孕育新场景、成为新入口，如答疑、问题排查等。
关键节点上的交互，技术确定性更高，更容易做到高ROI、高技术含量。
2023.06.13 优雅的技术Battle
复杂技术组织内的协作，一般要面对各种Battle。应对Battle有多种方式，包括
- 组织分工：这件事的主责是你、不是我，或反之。通常用不上，Battle起因通常包括分工不清（上级干预）
- 领域模型：理清领域模型，进而消除争议。缺点是，领域划分依赖预设共识、不同预设会得出不同的领域模型，预设受限于组织结构、技术经历等多重因素（多方演绎）
- 管理规范：规范就是这样，你的做法打破了规范。缺点是，规范是单边预设、缺少共识，没有说服力（单方演绎）
- 就事论事：使用技术视角，就事论事、case by case的否决或共识。目前看，这种拼技术能力的Battle最干净，但也会有例证不全的问题（正反归纳）
技术Battle的过程，是把事情想明白的过程，也是锻炼组织、演绎、归纳能力的过程，值得珍视。
2023.06.06 人是最大的康威定律
在自然竞争的环境下，人是最大的康威定律。有什么样的人就有什么样的组织，组织决定了技术和产品形态。
所以，领导者在建队早期就要明确人才目标，为将来留足潜力。
2023.05.31 基层管理者的主责对象
基层管理者的责任对象，主要是上级和下级，谁应该是主呢？因公司而异。
以做事为主的公司，基层管理者的主责对象是上级，命令下达是主要职责。集权的组织结构，会进一步加强这条主责链路。
注重人文关怀的公司，基层管理者的主责对象是下级，在命令下达的同时、也会有非常顺畅的民意上传通道。人文关怀有助于员工形成归属感，最终促进组织绩效。
2023.05.05 技术集权的利弊
技术集权是一种技术组织的管理方式，典型特征是少数人决策、其他人执行。技术集权有如下特点：
- 目标管理上，集权组织决策效率高、执行能力强，但强依赖决策者的个人能力
- 组织建设上，集权组织无法长期维系，典型的集群病包括组织官僚化、个体丧失创造性、中层空间被挤压
最理想的组织模式是，在快速决策时采取集权方式，在稳定和发展阶段更倾向于民主。
2023.03.02 制度设计的四象限法
制度，首先是管理个人行为对人与人之间的影响，其次才是管人。按照「个人行为对自己&他人的影响」，可以把制度的作用划分为四象限，如下，
- 自己获益、他人受益。制度上要 鼓励
- 自己获益、他人受损。制度上要 限制或禁止
- 自己受损、他人受损。制度上要 禁止
- 自己受损、他人受益。制度上要 补偿
把你的制度设计，装进这四个象限之中、只能装进一个，假如装不进去或模棱两可，就说明这个制度是多余的。当然，好的制度先要设计一个好的框架、然后把所有制度分解到这个框架，类似美国三权分立的政治制度一样。
2023.02.08 定期review目标
1年以上的长周期项目，需要以H为单位、定期review目标。
一方面，项目不同阶段，问题有主次之分，目标应该聚焦主要问题。另一方面，随着实践的深入、参与人的认识会逐渐成长，可能会修正目标。
制定、修正目标，是技术管理者的核心价值之一。
2023.02.01 制度和潜规则
某些规则，一旦被制度化文字化、可能招来法律纠纷，公司通常会采用潜规则处理、既不留痕又要达到制度效果。
潜规则的顺利实施，首先需要达成管理共识。实施方(HR)对管理者的宣贯要要求明确、不能再有模糊，管理者要能准确领会，这就要求潜规则要重点清晰、不能太多。法律风险，转化为组织管理成本。
潜规则落地到小团队时，需要变为明文制度、强硬共识，这件事由基层管理者负责。即使在小团队内，潜规则维护成本也很高，老人容易健忘、2年时间忘记某条小规则很常见，新人反复教化的成本也不低、还要给犯错空间。一旦没能达成共识，管理动作就可能引发法律纠纷、后果严重。
所以，公司创始人们，如果你真care、那就请制度化，如果不制度化、那就别用它强制管理(可以作为文化宣导)，既要又要的ROI真心太低。这也能看出，公司制度是否高明、跟创始人的段位关系很大。
2023.01.30 目标和手段
目的是正确的，就证明手段也是正确的，这是不对的。正确的做法应该是：手段必须配得上目的的崇高。
2023.01.28 管理梯度的组成特点
管理梯度，通常由不同能力梯度的人员构成。不同能力梯度，表现形式可以是年龄长幼的不同代人、也可以是闻道有先后的同代人，不同代人居多。
相同能力的人员，很难长时间处在上下级的位置，不能构成稳定的管理梯度。
2023.01.28 制度落地依赖好人
集权式管理，需要好制度、也需要落地好制度的人。
管理不是全自动化流程，现有技术无法自动的检查输入、监督过程、验收输出。制度告诉人类该怎么做。
人类有自主意识、工作效果有好有坏，要找到工作效果好的人落地制度、才能保障管理结果。落地制度的优先级是：验收输出、检查输入、监督过程。
随着技术水平的提升，制度会不断被自动化、对人的依赖会减少。但很长的阶段，管理仍然要靠制度维持，制度落地依赖好人。
2023.01.20 组织的新陈代谢
组织要新陈代谢，每年应该更换10~30%的人员。像生命体一样，组织通过新陈代谢，引入负熵、维持各种有序的状态(哪怕是有序的衰老)。
经济形式好时，行业发展会刺激个人，个人会主动更换组织；经济形式不好时，则需要管理者强制人员更新、保持组织活力。
对个人来说，被更替听起来是一件坏事，但事实并非如此。在新组织中找到价值输入、远比躺平要好，人最宝贵的是生命时长、不容低效浪费。
2022.12.27 公司的经营特点
从成长战略来看，公司可以分为创新型、跟随型两种。
原创型公司，通过商业或营销上的创新，开创出一片蓝海、供自身成长；这类公司的成功，更多的是商业或营销战略的成功。
跟随型公司，通过模仿快速入局红海，再通过提升经营效率、长跑胜出；跟随型公司早期具备了资本或流量优势，非常强调经营效率。
从个人职业发展看，工作在原创型公司会是幸福的、体面的、有所作为的，在跟随型公司则可能是螺丝钉、被各种压榨。
2022.10.21 管理者的职能分类
管理者可以分为人事型、业务型两类。人事型管理者需要做好后勤，为业务骨干创造便利的工作环境。业务型管理者要非常熟悉业务，具备决策所需的所有知识和信息。
呜呼哀哉。
2022.10.03 描述清楚目标
爱人财务负担较大，假期找她聊再分配方案，首先要弄清楚现状。我没有交代目标，直接提议审计上个月的流水；爱人理解成不信任、非常抗拒，接下来可想而知。回想起来，工作管理中我也经常发怒、认为下属没get我的解决思路。这是同一类问题。
沟通时，没有清晰描述背景和目标、上来就直接讨论解决方案，对方无法快速理解、甚至误解，导致不欢而散。这是我个人易怒的一大原因，需要重点管理起来。
感谢那些悟性迸发的瞬间!
2022.08.24 技术评审的局限
技术评审只解决大面的架构风险，不解决细节的逻辑缺陷。负责人要明确主责意识，自己保证设计质量、不能指望他人。
对于技术评审，大家要建立正确的认识。技术评审，不能取代负责人自驱。
2022.08.17 架构和运维的分工
架构主纵，负责数据面、控制面；运维主横，负责管理面。运维根据场景，将纵向烟囱、连接成全局的&可交付的管理面。
组件能清晰的定义数据面、控制面、管理面，应用则相对复杂。应用的共性逻辑，已被抽离出来、建设为中台，如CD、服务治理，这些就是”应用的组件”，举例如下
- CD：架构建设命令通道、文件通道、数据通道，运维建设CD管控中心
- 服务治理：如流控，架构建设Mesh网关、劫持数据流提供控制能力，运维建设RD自助的流量管理平台
当前，架构偶尔会建设管理面，运维也会尝试建设控制面，但通常都没有拿到好结果。这里的运维指的是SRE。
2022.08.10 向上管理的协作模型
向上管理的主要内容是做事和沟通。向上管理模型，以沟通方式为横轴、以做事方式为纵轴，做事方式分为事务型、谋划型，沟通方式分为外向型、内敛型。谋划型是指一个人喜欢出主意、不喜欢做具体事务，事务型则相反。外向型指的是一个人乐于横向沟通协作，内敛型则喜欢管好自己。
如果上下级的沟通方式一致、都是内敛型或外向型，那么上下级的非正式沟通比较容易合拍；这个时候，你应该有意识的增加非正式沟通、拉近和上级的联系，比如主动发起闲聊等等。如果上下级的沟通方式不一致，则需要下级主动扮演上级的助手，比如上级外向时、下级主动多做一些研究型工作给上级减压，上级内敛时、下级主动多做一些联络型的事情。
如果上下级的做事方式一致、都是谋划型或事务型，那么恭喜你、上级完全懂你在做什么，但也意味着你必须把事情做到最好、要不然上级可能瞧不上你。如果上下级的做事方式不一致，则需要下级主动扮演上级的助手、帮助他补足短板，比如上级擅长出主意、下级就应该多执行，上级擅长执行、下级就要做好幕后军师。协作好了，上级就会更依赖你、对你的授权更充分，你的发展空间也就更大。
带团队的关键点是：定方向、搭团队、做事、沟通。其中，做事、沟通是向上管理的主要内容，因此才有了上述模型。
PS：管理者的任务首先是定方向、搭团队，其次才是做事、沟通。初入管理者要勇敢的下放运营事务、聚焦长期价值。
2022.07.28 改善团队氛围的要点
改善团队氛围的要点，包括但不限于：
- 分工：工作责任边界清晰
- 成长：个人成长路径明确
- 组织：团队内部磨合到位
比较以外的是，分工居然是团队氛围权重最高的项。
2022.07.13 向上管理时要敢SayNO
向上管理时要敢SayNO。你不表达不满，领导就以为你没意见、以后更会理所当然。你表达不满，有可能不被采纳，但连续反馈总能触动领导思考、有可能改善情况。
管理生态的建设，不是一言堂、而是一个反复折中的过程；为了组织健康存续，每个人都应该敢于SayNO、积极暴露问题
2022.06.23 充分放权、做好补位
管理意识上，要开放心态、充分放权，不重复投入、成就下级。在组织结构持续扁平的过程中，发挥好TL的自我价值。开放心态，冒着边缘化的风险充分放权，这是一个煎熬的蜕变。
管理过程中，要识别重点、做好补位，兜底最坏的情况。2022H1的教训是，重点项目的管理过于宽松、卡位不足，失去了对最坏情况的兜底能力，H2做好关键人关键节点的合理卡位。同时避免挤压下级空间。
特别的，放权可以显著提升下属的自信。之前管的细、太扣问题，下属心理负担大，工作结果差。放权给下属自主决策、同时加长了管理跨度，结果较好、下属恢复了自信。管理者重点放在定目标、要结果，过程管理以协助为主。
2022.04.22 管理需求可以被前置消灭
优秀的团队不需要太多管理、设置好目标就行，弱鸡团队才需要各种管理。聪明的TL，首先应该要选对人，把管理需求消灭掉。
2022.04.21 项目验收机制
团队比较弱鸡时，需要设计验收机制，用管理手段、保障项目质量。验收机制，包括：
- 设计验收：拉会、验收设计，产品功能为主、技术为次。目的是避免返工，适用于核心功能系统
- 结果验收：拉会、验收功能，要看实物、不要相信他说了什么
以下，是项目验收机制的背景：
在项目管理过程中，经常出现一些蛇尾现象，比如流程没做发布、功能没做验收、改进项长期搁置。平台建设、业务支持等场景也存在类似问题。 针对这个问题，我们约定了严格的验收环节，形式一般是拉会，内容以代码CR、功能验收、心得分享为主。虽然解决了蛇尾问题，但管理成本也挺高，需要继续摸索。
2022.03.02 如何参与技术一线
结论：管理者想要优雅的参与技术一线，就需要
- ① 目标明确的筛选组织。关注公司的管理容量、组织风格、领导特点，强调人人连接
- ② 做好个人的管理修养。做到充分放权、降低管理压力，重点卡位、掌握关键一线，经营二手经验
如果职业生涯希望更多的技术成分、而不是纯管理，就需要处理好管理和技术一线的关系。
管理者容易脱离技术一线。可能有如下原因:
- 组织特点。组织结构、领导风格等因素，可能造成中间层管理者失去人人连接、需求输入不足，造成对一线的疏离
- 个人投入。管理本身非常消耗精力，忙于管理+管理半径过大 就意味着投在技术上的时间不足
- 个人错失重点。项目有很多、个人有好恶，稍不留神就会错失重点项目，导致出现重大的一线遗漏，遗漏多了就出问题了
长期脱离一线会带来很多问题。包括但不限于:
- 专业能力蜕化。不了解产品技术，不了解业务现状，失去技术/架构判断力，技术决策就是空中楼阁
- 很多管理者就是因为专业能力蜕化，职业生涯过早的进入下坡路
- 团队价值降低。没有了技术专家/架构能力，技术管理者就成了无根之萍，向上会失去领导信任、向下会失去团队掌控力、横向协作也难以展开
管理者如何优雅的参与一线呢？当前还在实践总结中，有几点体会:
- 选择组织。选择管理容量足够、组织风格宽松、领导懂得放权的组织，维持好向上的、平级的人人连接。这一项最重要
- 组织制度一旦开始演化，就会有自我强化、收益递增的特点，很难被改变。所以，做选择、而不是改变
- 充分放权。维持适度的管理半径(5-10为宜)，合理下放部分管理工作，让自己有时间、有精力参与技术建设
- 重点卡位。识别出关键领域的关键事项，抓大放小、合理卡位，掌握关键一线；识别的过程不能偷懒
- 二手经验。二手知识足够用，事后找关键角色，给你讲解重点、现场实操，会比亲自参加各种细节沟通更高效
当然，管理特点高度依赖公司资源环境、高度个性化，需要因地制宜。前路漫漫，虽千万人吾往矣!
2022.03.02 如何看待跨级管理
跨级管理，指的是：Leader跨过你、直接调度你的下级资源。跨级管理，原因可能有几个方面：
1、团队规模过小。业务萎缩、团队规模过小时，上级自然有余力向下扩展、跨级管理（水浅王八多）。这是客观原因 2、领导意识不足。领导尚未脱离个人贡献者思维，喜欢直接参与一线、双脚离地就有危险感，这种情况通常发生在新进管理者身上。这是主观原因 3、组织风格使然。强权CxO、过于集中的OKR、细节控等等组织风格，都会加剧跨级。这是组织特点 4、个人掌控欠缺。管理者过分放权、丧失了对关键一线的宏观掌控，久而久之上级就习惯了跨级领导、并理所当然。这是个人原因
对于个人掌控能力欠缺，可以通过管理手段来改善、规避，如加强宏观把控、关键节点验收。加强管理掌控能力的出发点应该是充分的善意和信任，而不是排挤贤能、挤压下一级管理空间。特别的，充分信任的放权并不会直接导致架空、验收不足才会。
2022.02.24 警惕工作中的PUA
知识输入：情感PUA，也称为情感操纵、煤气灯操纵。煤气灯操纵三个阶段就是一个自我认知逐渐瓦解的过程，最初，被操纵者只是轻微的自我怀疑，之后会走向不断自我对话、辩论的阶段，直到最后的自我失去。只要你相信 操纵者的认可能让你提升自信，那你就会成为煤气灯操纵者的潜在对象。
自身经历：细细回想，当年被情感PUA了。当年不懂的、现在明白了，也是莫大的进步。所谓温故而知新。
知识升华：反观工作方面，自己是否在被某种形式的PUA呢？「如果你感觉到，上级的认可让你提升自信、获得快感，上级的怀疑让你迷失自我、精神沮丧，那你很可能正在被PUA」。
2022.02.21 关于红脸白脸的思考
管理者要维持温和的权威，多伴红脸、少伴白脸，多种花、少栽刺，不能代替下级管理者、行使惩罚。
手下一个小组，TL性格温和、无法充分利用人力。我这里看不下去了，就主动跳出来、拌白脸，”压榨”摸鱼的员工。几个月下来，因为无法实时监督、压榨的效果并不好，反而引起了不小的意见。小组TL也没能主动提升管理能力。
这个Bad Case说明，”吃自己的狗粮”、管理责任不能外溢。小TL要尽本分，为结果负责。更上一的管理者，做好红脸、怀柔团队，可能会更好。
2022.02.19 关于管理半径的思考
结论：管理半径不能太小，以5-10人为宜；太小，意味着和一线的人员、业务、技术脱节，会让管理者陷入被动局面。
在向上管理得当的前提下，管理半径不能过小。过小的管理半径，意味着和一线人员、一线业务、一线技术的脱节，让管理者陷入被动局面。
从个人感受来看，3个及以下太小，当初放权过于激进、现在感觉到被动了。师傅建议10人半径，等有机会了要尝试下。
2022.02.15 管理工具之RASCI矩阵
RASCI矩阵的中文名字叫责任分配矩阵。在项目管理活动中，RASCI矩阵在项目初期可以协助规划、澄清成员的权利与责任，也可以在项目中后期作为撕逼依据。RASCI定义如下，
- R(Responsible)执行人: 干活的
- A(Accountable/Approve)负责人: 拍板的，定调的，出钱的
- S(Support)支持者：有钱出钱，有力出力；S角色有时会被省略掉
- C(Consulted)顾问: 专家团，顾问团
- I(Informed)知情人: 邮件中被CC到的人
借用FinOps的组织规划图、举个栗子：
2022.01.29 招人标准的反思
分析了下自2019年建队以来、所有队员的在职情况，有如下几个关键信息：
- 岗位匹配度高、主观稳定意愿强烈的，能在职2年以上、并成为团队中坚；这类人通常能成长到中高能力，留下来的都不是废柴
- 个人能力落伍、难于择业的，也可能在职2年以上，关键是发掘与之匹配的低阶岗位
- 岗位匹配度中高、主观稳定意愿尚可的，2年左右会出现离职潮；2年是个大槛，经过2年积淀、大部分人有条件选择外部诱惑
- 岗位匹配度低、主观稳定意愿尚可的，最多坚持1年；这类人中，能坚持到1年的、人品都不错
- 岗位匹配度低，主观稳定意愿一般的，半年内离职；通常是无法适应团队，也有骑驴找马的人
从统计数据看，在职时长主要取决于岗位匹配度、主观稳定意愿，跟个人能力/潜力没有明显的相关性。而我之前一直把个人能力/潜力作为招人的首要因素，看来是错了。接下来会对招人标准做如下改变：
- 招聘首先看岗位匹配度，其次看主观稳定意愿。不单纯追求能力/潜力，但也要警惕俗人扎堆
- 将候选人划分为2年期、4年期，事前明确岗位的在职时长预期。2年期是干将，4年期是团队中坚
- 重点识别骑驴找马的候选人，事前尽量拦截，不幸事后、则永不录用
当然，上述统计结论也可以用做员工的辅导激励，对于岗位匹配度不高的人员要及时调整、避免流失。
岗位匹配度，是管理者对员工和岗位匹配程度的判断，这个判断会结合建队目标，虽然主观、但也比较准确。
2021.12.29 柔情管理不可取
柔情管理不可取。管理者不是和事佬，不能过分依赖员工主动性，对员工不好意思管、不敢管，表面看是柔情、实则是不作为。
柔情管理者，一旦遇到不自觉的人，整个团队的人效就会很差。这是管理事故。
2021.09.29 能力和地位要匹配
《周易·系辞·下》有云：「德薄而位尊，智小而谋大，力小而任重，鲜不及矣」。地位过低、过高，都会有问题。
2021.09.23 隔级指导压力山大
结论：导师和新人的能力代差大于1代时，导师煎熬、新人承压，培养效果会打折扣。隔级指导本质是团队梯度问题。
DEV方向人员流失严重，我亲自担任了一名校招新人的导师。辅导期间，很多我认为是必备的常识、技能，新人都不具备，部分错误在我看来甚至很低级。几次下来，辅导过程就比较严厉了，新人承压。回想起来，这已是第二例Case，之前一个起点差、潜力不足。
问题出在「隔级指导」上。隔级指导本质是团队梯度问题。导师和新人之间，如果能力代差大于1代、对导师来说就会比较煎熬；如果遇到急脾气的导师，新人就会承压、辅导效果也不会太好。
2021.07.15 团队要适度的讲人情
团队内部需要讲人情、有温度。针对团队老人，需要给与足够的宽容和帮助。借用《潜伏》吴站长的两句话，来表达下我的团队人情观：
1、没有人情的政治是短命的。人情无需分敌我，何况是一个团队内部!
2、不注重情分的人难堪大用。无情未必真豪杰，怜子如何不丈夫？心怀感恩，方能致远。
当然，人情观的底线是不能损害团队重大利益。毕竟，公司是盈利组织、不是慈善机构。
2021.06.16 团队要明确价值定位
团队需要定义清楚核心价值，然后由核心价值、推演出不同阶段的工作目标。价值是目标的筛选器，目标是价值的实现路径。
上述思考，来自上半年的惨痛教训。之前，不太重视团队价值的定义，觉着太虚、浪费时间。上半年，老板、老板的老板建设预期高涨，容器改造、多云容灾、网络基建同时上马，建设目标不断提升；OP在稳定性上的投入被严重挤压，最终酿成2起重大故障。对应的，绩效评估也暗淡收场，虽然建设目标达成的不错。这时，我才突然意识到：稳定性这一核心价值没有达成，其它所有的建设功劳都显得那么苍白无力。
经此一役，我深刻的体会到「明确定义团队核心价值」的重要性。团队价值是筛选器，它决定了团队要做什么、不做什么、重保什么、放弃什么，特别是资源有限的情况下。
2021.04.22 导师对徒弟是有限责任
导师对徒弟是有限责任。如果一年还没达标就放弃吧，不管这人有什么优点；培养不起来，本身就是最大的问题。
我用半年的精力，把人从入门、培养到能做事，接下来一年半始终没能进步到极致。现在想想，他本身就有天花板，早点Fail、让他找到合适的位置更好。心慈，不一定是好事。
2021.03.02 高阶招聘
高阶招聘，需要同时做到：调度资源、掌握人脉。且人岗匹配。
2021.02.01 向上管理的职责
中层管理者的向上管理职责之一，在于：为更高层老板，争取决策的时间、资源、主动性。
2020.12.20 成果和贡献的平衡
年底打绩效时，经常发现某些成员的OKR得分远高于/低于管理感受。分析发现，得分过高的成员以”从0到1”的工作为主，得分过低的则以”从1到100”为主。
人性倾向于重成果、轻贡献。成果是从0到1的拓新建设，对比显著；贡献是从1到100的持续运营，默默无闻。在没有约束的情况下，公司文化很容易变成重建设、轻运营，重成果、轻贡献；久而久之，没人再愿意做从1到100的事情，而这部分工作是公司运转不可或缺的。
合理的绩效目标制定、结果评估可以缓解这个问题。在绩效目标制定环节，平衡每个人预期的成果、贡献比例，避免明显偏颇；一般的，平台、项目KR是成果，指标、运营KR是贡献。在绩效结果评估环节，管理者要有意识的平衡成果和贡献；比如，采用”OKR客观打分+组长主观打分相结合”的方式，两个排名差异大的成员重新review。
2020.12.10 价值来自关键节点
个人价值， 在于「你是否处于某个关键价值的必经节点」，团队分工亦是如此。
2020.07.19 领导团队的关键点
领导团队的关键点有：看方向，带人，做事。最近一年，在带人、做事方面都算过关，但在看方向上做的较差。要么主动思考、要么被安排，方向大事容不得一丝懈怠。
2020.03.25 关于分阶段交付
人力有限时，大项目往往要分阶段交付，每个阶段交付1+个相对独立的产品功能。
Dev同学可能对分阶段认识有误区，可能会站在技术或代码开发的角度来分阶段，导致无法持续交付产品功能。这一点需要关注。
2020.03.15 一线同事能力较差时，如何保证结果质量
由于历史原因，团队会留下了一些能力较差的一线同事，且主动/被动进化的效果不理想。为了利用这一部分人力，同时达成高质量的结果，团队采用了 架构师带队、一线人员执行、团队集体验收 的合作模式。
架构师是负责人、责任人，协助梳理目标、分解里程碑、制定验收标准、定期检查。一线人员拿到的是一个可执行、能度量的任务，不需要太多思考就能准确实施。架构师定期组织一线员工检查中间状态，整体完成后团队成员一起检查结果、确保效果高质量达成。
关键点：推动被动老员工的个人提升有难度时，可以选择用合理的分工来充分利用人力。
个人
2024.06.16 人生格局
上层社会人捧人，中层社会人比人，下层社会人踩人。格局提升，要从思维方式、做事方式开始，不纠结于低层次的人和事。
2019年写过一篇「不纠缠于低层次的人和事」的感悟，当时大概是自己经历的人比人阶段。回首往事、把间断的点连成一条线，看到自己打怪升级、持续成长，很是欣慰。生命不息、奋斗不止，继续加油!
2024.01.19 对抗PUA
真正的自由，是有勇气被人讨厌，”不在意别人的期望”。世上也只有一种成功，那就是 “用你喜欢的方式度过一生”。
BTW，HRBP是逆天的工种，很难让普通员工信任。本质是，资本家和工人的阶级对立。
2023.11.21 刺猬三环
ikigai四环模型，即热爱、擅长、酬劳、价值(被需要)，将你热爱的、擅长的、赖以生计的，与价值(社会需要)统一起来。如下图。ikigai是一个日本概念，其中iki生活、gai意义。
与之类似的刺猬三环，热爱、擅长、酬劳，酬劳也被换成机会。刺猬三环是ikigai的子集。
2023.10.18 人生大事
夜梦己卒，未有所施、怅然不甘，遂以笔墨传书，假友人、成吾夙愿。
盖人生之大悲，莫过于壮志未酬。
2023.10.12 道术器
道术器：形而上者谓之道，形而中者谓之术，形而下者谓之器。君子不器。
《易经·系辞》有云：形而上者谓之道，形而下者谓之器；化而裁之谓之变，推而行之谓之通，举而错之天下之民、谓之事业。
2023.10.11 优绩主义
优绩主义(meritocracy)是一种理念或制度，它强调：个人凭借才能和努力，获得机会和成就，而不是依靠出身、财富或背景。在优绩主义原则下，个人成就被视为个人价值的主要标准。
东亚社群深受优绩主义的影响。儒学积极入世和奋发有为的教义，激发了社群内的个体竞争和攀比，个人成就成为主要的价值判断、且标准一提再提，大部分个体被裹挟前行、严重内卷。个人成就不是个人价值的唯一标准，不断攀升的个人成就欲望更不应该成为唯一的人生目标；身处这样的文化圈需要时刻反思、避免被裹挟。
2023.09.15 北宋大儒张载
为天地立心，为生民立命，为往圣继绝学，为万世开太平。这样宏大的人生意向，出自北宋大儒张载的《横渠四句》；张载即张横渠，北宋1020年—1077年人。
张载的宏大意向，需要同样恢宏的北宋王朝。人啊，最终还是有时空局限的。
2023.09.09 模型化学习法
只有足够简单，知识才能被快速吸纳、精准使用，人生才能博闻强识。而模型化、不求甚解(逐渐完善)，是简化知识的有效方式。
知识被模型化，才有利于快速吸纳、精准使用。《五柳先生传》有云：好读书，不求甚解；每有会意，便欣然忘食；快乐的模型化，境界很高。另一方面，知识太多、人生太短，只有简单、才能博闻。《庄子·养生主》有云：吾生也有涯，而知也无涯；以有涯随无涯，殆已。心有戚戚。
模型化体现了系统思维，是自顶而下的设计，更有利于博闻强识。万维钢的《佛畏系统》讲到，众生畏果、菩萨畏因、佛畏系统，就挺好。
2023.09.09 人际关系的博弈均衡
以自我为中心、把关注点放在自我提升上，通过改善自身、间接改善和他人的关系，这是一种更富智慧的人际博弈均衡。类似《国富论》。
说到底，生命只有一次，个体都是孤岛、人人之间只有少量连接，完全没必要以对方为中心。
2023.09.07 再论人际关系的宽度
人际关系的宽度，基本上只有10年、前后各5年。人的思维，也会受限于自己的人际关系带宽，并产生一定的固化和老化。
对于年轻人来说，你必须承认老一辈的思想固化，你必须通过实力、把它们打醒打掉。
2023.08.29 跨领域学习
个人在走专业化道路的同时，可以拿出10%的时间来学习其它学科。跨领域学习，目标不是面面俱到，而要取其精华、并为专业所用。
以芒格为例。在生物学领域，芒格非常重视学习进化论，他认为在一个行业乃至整个商业史中、公司的兴亡更替同样符合生物进化论的规律。在数学领域，芒格很推崇排列组合，他认为万事万物都是元素排列组合而成、分析一件事就要找出元素&弄清楚元素的排列组合方式。芒格还重视历史中的商业史、统计学中的高斯分布、物理学中的平衡和临界质量、工程学中的断裂点理、还有误判心理学等等，这些都是跨领域抓重点的思维。
2023.08.16 龙场悟道
2022H1的作业帮，就是我的悟道龙场。感谢这一段如芒在背、生死攸关的经历。
2023.06.29 反思之反思
反思是思之再思。反思不一定是事后复盘，也可以是事前推演。
反思有三个境界：小反思之于行动，中反思之于目标，大反思之于心智模式。行动、目标、心智模型，我只所得也。
2023.06.27 德在人先利在人后
德在人先，利在人后。
2023.06.08 创新涌现
大部分时候，创新是日积月累的结果，但表现形式通常是突然涌现。就像ChatGPT一样，模型参数和训练规模足够大时智能就涌现了。
读书破万卷，下笔如有神。读遍唐诗三百首，不会作诗也会吟。这种感受，是如此的真切。
2023.05.31 人脑的训练模型
人类认识客观世界的过程，是一个典型的训练过程。人类通过感觉器官、采集客观事物的信息，这些信息经由人脑这个有状态大模型、进行训练处理，最终形成或更新人对客观事物的主观知识。大脑就是一个海量参数的大模型，信息采集、训练处理、更新知识是多轮训练，结果就是人对客观世界的知识不断积累、创意涌现。
人类评价客观世界的过程，是一个典型的推理过程。人脑已经建立了客观世界的知识模型，当遇到客观事物时，人类通过感觉器官、采集客观事物的信息，经由人脑大模型的正向推理，产出之前已经建立的知识。
以LLM类比，影响人类个体成长水平的因素有：先天智力(大模型)、知识和实践(数据集)、勤奋(训练规模)、良师益友(提示工程)等。先天智力的差异不会太大，就像各家大模型的差异不太大一样。
2023.05.31 食物味道的原理
食物的味道是人脑主观解读出来的。味道，是食物经由人体的感觉器官、大脑(有状态)处理后，在人脑中形成的主观食物模型。
在感觉食物味道的过程中，既有舌头、眼睛、耳朵、鼻子、手等感觉器官的采集信息，也有认知、记忆、想象、直觉等既有认知(状态)的处理加工，大脑整合主客观的多方信息后、形成我们对味道的完整印象。
2023.05.22 殊途同归的认知
上古学院是一个奇特的封建迷信组织，身处其中的人都建立了迷之信仰，按照这种信仰体系的指导，很多人收获了认知、心灵、生活上的升华。
为什么封建迷信也能帮人建立完整的认知？个体认知，是特定知识水平上的逻辑自恰，核心是说服自己、产生正反馈，底线是不挑战法律道德。如果能帮人打开格局，那么这个认知体系就是有帮助的 —— 条条大路通罗马。
2023.04.24 继承与创新的侧重
我们不得不接受一个事实：个人认知成长，绝大部分来自继承、少量来自创新。
知识领域浩如烟海，个体时空有限、能够专注于特定领域点，这就决定了个体认知成长要以继承为主。创新是人类大厦的制高点、是千里之行的跬步，创新机会虽少、但意义非凡。
正确设置继承与创新的占比，有利于提高人生利用率。
2023.04.10 工作中的螺丝钉感
螺丝钉感，指的是分工带来的职责错觉(组织人)。在大公司中，它会让人觉得自己身处一部庞大的机器中，这部机器设计很合理，而个人只需要像一颗螺丝钉一样、做好这个环节的事就够了。
螺丝钉感，是职场的认知牢笼，高度的场景化、边界化。它会像温水煮青蛙一样，让你逐渐丧失竞争力、葬送职业生涯。
2023.04.05 梦的解释
梦，无关乎吉凶、它是个人心理状态的反映，是观念、情绪、欲望的形象表达 —— 这是解梦的提纲挈领。
引用《成为自己的解梦师》一书的介绍。「梦是心理咨询师了解人心最重要的媒介。你可以把它理解为一种心理测验，梦不过是人的观念、情绪和欲望的形象化表达。而释梦并不是为了预测凶吉，而是为了了解自我」。
2023.03.31 警惕认知的牢笼
熟悉、适应一个场景，能协助打磨认知(认知的场景化)，但也意味着被场景圈养、无法再进一步。
人不应该被小范围的认知优势所局限，人应该敢于打破边界、主动求变，更广阔的场景、才能激发更宏大的认知。也请实时自省，警惕被设边界、特别是润物细无声的!
2023.03.30 认知高度场景化
认知是高度场景化的。认知，产生于、匹配于特定场景，也形胜于该特定场景(形成优势)，去场景化的认知大概率是低配的。
认知的场景化，本质是大量数据的刻意练习。
2023.03.30 司空见惯的原理
知识分为熟知、真知两类。真知是你真正知道的知识，熟知是你觉得熟悉、但是经不住考验的知识(司空见惯)，熟知类似于孤立的点、而没有形成知识网络。熟知，往往只能经受辩证法的第一问，无法回答第二、第三、第四问。
人的认知优势，体现在真知的占比，真知占比越高、认知优势越大。
2023.03.30 辩证法的步骤
旧认知 –> {质疑(提问题)-反驳-修正} –> 新认知
2023.03.22 信息渠道很重要
信息是认知的基础。认知升级是信息加工处理的结果，足够多的信息是认知升级的前提。
大部分人的大部分时间内，他只是信息的接收器、不是信息的原创者。信息渠道越多、你能收到的信息也就越多，信息渠道质量越高、你收到的信息也就越有用，对认知升级帮助也就越大。一本好书、一堂好课、高知朋友圈、高阶合作伙伴，这些都是很好的信息渠道。
牛人，可能并不是你认为的那种牛，他可能只是信息渠道更多更好、有人帮衬而已。在合适的年龄、迈过关键的坎儿，错过了就错过了，这也有信息渠道的原因。
2023.03.20 个人选择的自由
好的社会，应该是机会分层的社会；好的社会文化、制度，应该给个人选择的自由。不是每个人都要成为精英、不是每个人都要有成为精英的理念，普普通通、幸幸福福也是很好的人生选择。
只要方向正确、不反复，走的慢一点也无妨。1代人做不完，那就2代人、3代人去做，牺牲1代人换取后世幸福是没必要的，毕竟每一代人都有追求个体幸福的权利。
2023.03.04 人类关心孩子胜过关心父母
人类大部分个体，关心孩子远胜于关心父母，这很可能是自然选择的结果。物种要延续，就要把资源投在更具未来战略的方面，孩子是种族的未来、会收到更多的资源倾斜，老人是种族的”累赘”、很容易被抛弃。
作为意识觉醒的个体，当然不希望被过河拆桥，不同国家社会通过文化、制度等手段弥补自然选择的漏洞。古代中国有宗族礼教、官僚选士的约束，长辈社会地位很高、能调度的资源甚多(下层民众情况不太确定)。当前西方社会有完善的养老体系，在制度层面允许个体获得晚年幸福。
当前的中国，旧文化礼崩乐坏、新制度尚未完善，身处其中的老年个体要承受很大的偶然性。恢复旧时礼乐显然不现实，借助社会养老制度、提前规划+多方下注分散风险是唯一的选择。养老制度是资源的跨时空分配手段，它并不是一碗水端平的大锅饭，而是按照个体的社会贡献、多劳多得。聪明的个体，要提前规划、预置部分资产用于养老，剩下的就交给大势和命运了。
2023.03.02 35岁危机的本质
中国的80后、90后职业危机在35岁，欧美同代人大概在46岁，为什么呢？上一代人被”淘汰”的速度，取决于下一代人的成长速度(当然也跟上一代人成长减速有关)。
中国从1994年开始，工业化进入加速期、社会经济快速发展，年轻人的成长速度远超上一代，学习工作的经验积累也远超上一代。假设在美国，”80后”到了45岁才能被”90后”追上；在中国，因为发展太多、”80后”到了35岁就被追上了，提前了10年。生在这个伟大的时代，是我们的幸运、也是我们的不幸。
回到2023年，知识更迭速度比之前更快了。过去的知识产生速度慢，上一代人跟下一代人需要的知识差不多；但是今天，上一代人跟下一代人需要的知识可能很不一样。35岁危机的情况，可能会有过之而无不及，只有不停的成长、才能赶上潮流。
2023.02.17 格物致知
深度思考、格物致知，有点像。
2023.02.10 认知的进化模型
认知进化模型，是：在特定领域，用简单的算法、淘汰错误，经过多轮重复后保留下正确的结果。
以生物进化为例。蝙蝠、变色龙、响尾蛇，这些物种设计精巧、无比神奇，它们的”正确”都是建立在大量的”错误之上”。每个物种会产生大量有基因差异的个体，自然选择算法让那些跟环境不匹配的个体丧失繁殖机会，经过一轮又一轮的重复淘汰、最终保留下来的就是”正确”物种。这个例子中，特定领域是 地理环境中的物种繁衍，算法是 跟环境不匹配的个体不允许繁殖后代，错误、正确则是是否跟环境匹配。
认知进化的过程，就是在 ①确定领域 ②建立算法 ③不断去伪存真 的过程。不同领域，算法不同；同一领域，算法也要不断修正；不断去伪存真，要求持续实践、输入不能停滞。
之前个人的关注点是，不断深度思考、制定正确目标。用认知进化模型看，正确目标是淘汰算法的执行结果，其作用更多是驱动实践、确保输入不停滞。个人缺少独立的、系统抽象的「淘汰算法」，深度思考只是一种手段、不是淘汰算法（标准）。
2023.02.08 认知的场景局限
在特定场景下形成了的认知机制、模式，会主动扩张势力范围，不分场合、不分青红皂白地运行。一旦遇到全新的、风格迥异的场景，它就会对人的认知产生巨大的干扰和破坏。这是认知进化留下的「嗔念」，也说明了认知的场景局限。
同样的，经验、理论也存在场景局限。
2023.01.20 中国的分层特点
当前的中国社会是分层的，包括思想意识、文化程度、经济发展等等。
风格迥异的公司、人都能够活好，世界观要求同存异。
2023.01.07 60%法则
对于一个陌生且资源不足的领域，你必须建立60%的认知、才有可能拿到专业的结果，否则就很容易被行家欺骗误导、难以拿到好结果。GoodCase如表哥给小侄儿办户口，BadCase如安君办理经营贷。
如果资源优质、充足，则可以完全托付，如值得信任的友谊和人品。但我更倾向于，「和少数人讨论、由自己做决策」。
2022.11.01 以正合以奇胜
《孙子兵法·兵势篇》有曰：”凡战者，以正合，以奇胜。故善出奇者，无穷如天地，不竭如江海”。正指的是常规部队，奇指的是预备队，常规部队上要能战平、再通过预备队胜出。
普通努力只能让你不落伍，更多努力才有可能胜出。
2022.10.10 批判性思维
为什么需要批判性思维？为了「更好的提问、更好的论述观点，从而更好的认识这个世界」。
什么是批判性思维？批判性思维是对信息加以系统的思考、鉴别、评价、回应，是认知进化的过程。批判性思维不是杠精、不是怀疑一切，而是不断反思、理性回应。
如何做到批判性思维？一段论述通常由论题、论据、结论三要素构成。论题，以一个问题的方式提出来会更清晰。论据，要识别其中的价值观假设、区分事实和个人见解，尽量做到客观。结论，要紧扣论题、并避免非黑即白的二分思维。
价值观假设的一个例子，上大学是否有用。有个人，朋友A初中辍学后在社会中摸爬滚打、现在成为一个有钱的商人，朋友B读完了大学、毕业后进入了一家普通企业领着微薄的薪水；于是他认为，朋友A比朋友B更成功(论据)，进而认为读大学没什么用处(结论)。这段描述的价值观假设是，金钱是衡量成功与否的唯一标准。倘若你不认可他的价值观假设，你就可以回应：为什么金钱是唯一标准，人的品格、修养、思维、眼界却没有被纳入考量。
批判性思维有哪些误区？常见误区包括逻辑谬误、数据欺骗、被省略不提的内容、含糊不清的词语。其中，逻辑谬误、数据欺骗、被省略不提的内容，一般都是用部分信息或数据、推导出有利己方的片面结论。
批判性思维的生理原理？人的思考模式分为快系统和慢系统。快系统依赖经验和直觉做快思考，消耗精力少、能快速决断；慢系统是专注、理性的大脑慢思考。快思考是自然进化的结果，但缺少准确、智慧、理性、包容，批判性思维训练能帮助规避这些生理缺陷。
2022.10.07 时不我待
人生最宝贵的，是时间。保守导致的浪费，也是不能接受的。时不我待，请珍惜第二个十年。
假期花时间接待了很多朋友，不是炫耀，而是弥补社交欲望、追求心理满足。这样的时间投入虽然值得，但也应该控制总量，毕竟生命有限。
2022.09.04 房屋养护的思考
在西山林语租住了4+年、上周还房，房东很不满意房屋的保养状态。站在我的角度，多花10%租金就是为了省心、住个好房子，没有养护义务，我也挺愤怒。这件事上，双方都有道理。
在这之前，我完全没有房屋养护的概念。后来找专家了解了下，做的好的业主每周都会请小时工做保洁，云云。我也意识到，房屋养护是我的知识缺陷、需要尽快补起来。
比知识缺陷更有意思的，是愤怒的原因。我本次愤怒的原因是自己的无知，不能理解房东。人的愤怒有多大比例来自无知？非常值得警惕和自省。
2022.08.30 科学教育的路径
今天群友马驰发起论点：国内的教科书只会摆共识/让你学习，很少讲述问题来源、也很少提及公式/定理要解决的问题。深以为然。
成人的科学成长路径，大体是：日常实践->抽象问题->学习思考->产出解法->升华认知->指导实践。
对应到小朋友，可以将实践换成精心设计的实验，如：设计问题->引导学习->掌握共识->实验升华。精心设计的实验，也必须来源于现实世界。科学教育的目的，是培养小朋友解决问题的能力，而不是迷信前人故纸堆。
2022.07.26 哲思类文章的写作方式
哲思类的文章，一个好的写作方式是：以小故事做引子、深入思考得出认知。
小故事一类的素材，需要日常完成积累。比如，随手做笔记、随手确认出处等。
2022.07.26 砍断厄运链、及时止损
-
遇到厄运要坚决斩断厄运链，把损失限制在局部，避免雪崩式灾难。
-
止损和认命，是对自我的充分认知，也是对命运的充分敬畏。
-
心态会决定命运。人不会总是好运气，也不会永远背运，但坏心态会让厄运不断放大。
上述感慨来自吴军老师，起因是：伯奇尔被费尔蒙特皇后酒店拉黑的故事：
晒香肠时被海鸥偷吃 -> ①打海鸥 -> ②弄脏客房 -> 打海鸥鞋子掉进水沟 -> ③吹风机吹鞋子 -> ④期间接电话 -> 吹风机滑落短路、整个酒店断电 -> 被黑名单
2022.07.20 众利勿为、众争勿往
众利勿为、众争勿往，因为机会偏爱少数人、天上不会掉馅饼。具体的，
- 空间：机会永远是少的。众人都在争抢时，好运轮到你的概率很小
- 时间：机会需要提前布局。众人都能看懂、或形成风气时，大概率已经在时间上滞后了
- 逻辑：事情都是有两面性。如果大家都只看到了好、没看到坏，大概率是认识不深刻、有盲点，潜伏的问题可能会造成严重后果
2022.07.20 西方社会中的善意
今天听吴军的《谷歌方法论》，讲了东西方社会一些共同的善意点，先记录下来、后续有感后再拆解：
- 勿以小恶而忘大善
- 反例：一些员工离职，并非下家比前一家更好，仅仅是在前一家遇到了点不爽、就把之前的好忘个精光
- 之前座右铭是「心怀感恩方能致远」，勿以小恶而忘大善 似乎更贴近我的想法
- 分享利益，独立决断
- 分享利益：在大型组织中，用分享利益的方式、促成合力
- 独立决断：美国各级公权确实民主决策、效率低，但私营企业从来就不曾民主、甚至比中国还独裁；决策就要为结果负责
- 勿因人之短护己之短，勿以人之短炫己之长
- 勿因人之短护己之短：因为别人的短处、就尝试掩盖自己的短处。比如，被告的一方抱怨大家在高速上都超速了、他只是跟在别人后面，警察没有抓领头的却抓了他。通常，不问是否有理由做错事、而是确定当前是否做错了事，如果是、该怎么解决就怎么解决，做错事的原因是另一件事
- 勿以人之短炫己之长：反例，某个人讲，今天我赢了两位世界冠军；原来，他在国际象棋上赢了网球的世界冠军，在网球上赢了国际象棋的世界冠军。专业分工的社会，更关注你的第一专业，把第一专业要做到极致
- 谋事在人，成事在天
- 凡事谋事在人，成事在天。对待结果，心态要平和。知道自己不擅长什么事情，而且并不因为这些事情利益大、诱惑大而勉强承受，才是智慧的表现
- 凡人以识为主，以才为辅。见识比才干更重要
2022.07.14 深度思考
深度思考，是为了得出对客观世界 更深刻、更抽象、更本质的认识。
深度思考，不是一蹴而就的灵感爆发，而是多轮次、反复迭代后的升华。
对于问题思考，遵循「现象 -> 分析 -> 解法」的路径。对于外部输入，遵循「知识输入 -> 自身经历 -> 知识升华」的路径。
2022.01.12 尊重外驱
儿子的幼儿园放寒假，接下来的1.5个月、不再需要早上07:30送上学。缺了这个约束，早上赖床的习惯又回来了、睡醒后总要刷30分钟手机，导致上午到公司的时间推迟到了30分钟。等学校开学，一切又会恢复正常(暑假时已证实)。
自己从来都是强自驱的人，但面对早上赖床，依然需要一个恒定的外驱、来保持习惯。很多好习惯本是逆天而行，依靠本心容易懈怠。
承认人性的合理，跟自己和解；利用外驱维持好习惯，这并不可耻。个人如此，团队亦是如此。
2022.01.09 创投界的技术前瞻性逻辑
对比甲方公司、创投界，两者对新技术的态度迥异。这是为什么呢？
两者拿收益的时代不同。甲方公司利在当下，更愿意使用稳妥的成熟技术，也没必要冒险；甲方往往已经初具规模，因此最低成本的把握当下最重要，偏向更成熟、更便宜的保守技术。创投界则压注将来，技术起点足够先进才能实现未来盈利；创投界的技术变现需要一个实施周期，因此技术起点必须足够前瞻、以至于在公司成熟时正好处于一个技术高峰，否则就是在创造过时的技术，所以创投界必须关注技术的先进性。
看似水火不容的理念，背后都有其自恰的逻辑。同理心思考，挺重要。
2021.07.18 生命的意义
当他回首往事的时候，他不会因为虚度年华而悔恨，也不会因为碌碌无为而羞耻；这样，在临死的时候，他就能够说：”我的整个生命和全部精力，都已经献给世界上最壮丽的事业 —— 为人类的解放而斗争” —— 摘自《钢铁是怎样炼成的》
今天北航故地重游，和两位同窗走走老路、吹吹牛逼、回首往昔。大家都有了属于自己的精彩和遗憾，不无悲伤、也算完美。每个人都可以有自己的追求，我只愿：生命不止、奋斗不息!
2021.05.16 职业生涯的长期主义
做职业生涯的长期主义者。
除了明确职业目标、有效利用时间外，也需要尝试增加生命长度。「增加生命长度」，这一点很容易被忽视!
2021.04.22 持续成长最重要
隔壁的例子。被下属顶替了，不是因为下属太优秀，而是因为上级不再成长。他山之石，历历在目。
2021.04.17 人际资源的年代局限
人际资源有明显的年代局限，一般是上下5年。对应的，个人职业高峰，最多也就维持10年。跨1到2代、建立年轻化的工作联系，有利于打破该局限。需要刻意为之。
2021.04.16 体系化总结和产出
工作可以很琐碎，但产出必须体系化。体系化，才有可能固化为知识、方法论。
体系化产出，依赖周期性总结。周期可以是天、周、月、季、半年、年，取决于工作环境。月度够用。
20220714按：之前更重视形式上的总结，对体系化产出并未做要求。这样不对。体系化产出才是目标，应该更被重视，按照这个要求做了半年、效果显著。
2020.11.30 警惕舒适区
今天面试了一位候选人。他有13年运维工具产品/架构相关的工作经历，本次工作希望转入SRE、以实践落地其工具创意。考察发现，该候选人没有完整的运维工具体系知识，相较13年的领域工龄着实可惜。
工具创意可能就是他的舒适区，13年时间沉浸其中，忽略了体系能力的建设。再加上知识更新不及时，就这样失去了竞争优势。想想自己，也是偏执于工具创意，甚至建立起了小范围的优势。后续一不小心，可能就掉在舒适区、走不出来了。
以此为鉴，警惕舒适区、加强定期反思。
2022.07.18 刻意练习
体系化的成长，来自：1分培训、2分交流、7分练习。刻意练习，就是带着理论做实战、边实战边吸收升华理论；只有升华后的理论，才算真正被吸收。
最近半年借口太忙，在刻意练习上投入的很少，导致能力体系进步较少。回想一路走来，每次实质性突破都有刻意练习的影子。定个小计划，后续每周留2-5个小时做刻意练习，加班很关键（事后证明，上午早点来公司、比加班效果好）。
2019.04.10 不纠缠于低层次的人和事
在XJ运维工具团队就职期间，曾因竞争TL和某Peer陷入了半对峙状态，导致大小事陷入了无谓争执，难以做到个人正直、难以摆正公司团队个人的关系。这段时间，我陷入了严重的小格局，成长出现了重大扭曲。之后，我跳出了运维工具团队、去到SRE小组，通过更换空间结束了恶性循环。这之后，虽然也会有些许工作中的争执，但再有没有脱离过正直的初衷。
现在想来，低层次的人和事、往往能唤醒人性的阴暗面，进而拉低一个人的层次、使人陷入小格局。解决的办法，包括
- 预防：拉起警戒线。识别、回避低层次的人和事
- 免疫：提升个人修养。降低人性的阴暗面被触发的几率
上述感悟，是被炸哥的文章《不纠缠低层次的人和事》唤起的。
2019.04.04 百度是运维界的黄埔军校
百度背景的运维人员，活跃在国内互联网领域的大部分公司。为什么百度能够成为运维领域的黄埔军校呢？在我看来有如下几个原因，
- 业务发展早：百度搜索业务的黄金期来的更早，业务推动了运维团队的快速成长
- 技术成熟快：百度更加技术驱动，能够更好、更快的将运维体系打磨到技术成熟
- 人才流动频率高：百度身处国内互联网中心（北京）、公司文化层面也比较Open、后期业务增长乏力，这导致运维人才高频流出、加速了对国内互联网领域的占领
回头看看，造就这么一所成功的黄埔军校，既是幸运、又多悲哀！
2019.03.23 个人成长的总结思考
专业知识的积累，有如下两种模式。我个人是螺旋上升模式
- 连续深入：focus在一个领域上，持续的投入，最后达成专业能力。如，在监控方向一干就是10年
- 好处：有利于历史资源的积累，过渡相对平滑风险较小
- 不足：依赖公司在专业领域上持续的投入资源，依赖个人长期坚持的性格
- 螺旋上升：围绕着一个领域方向，间歇性打转，从不同角度深入对这个领域的沉淀。如，监控干2年、做SRE 2年、再回来做监控
- 好处：能够做到好奇心和专业性的折中，能够协助建立多领域能力、大局观
- 不足：在多个子方向间断性投入，往往伴随着历史资源的归零，如知识从头学起、重新组件团队、重新建立专业影响力等
个人成长的突破，有如下关键点，
- 领路人：在成长的关键节点上，往往需要领路人提供点拨或者资源，帮你完成临门一脚的蜕变。俗称贵人相助
- 自我进化：反思和开悟的能力，特别是关键节点，可后天培养（批判性思维、深度思考、体系化产出）
- 进取精神：永不满足的心态，永无休止的努力，破釜沉舟的勇气
- 心怀感恩：对于帮助过你的人要心怀感恩，特别是勿以小恶而忘大善
这是从滴滴离开前的思考，感谢滴滴给与的成长机会。
零星内容（思考过程、可能已经过时）
2023.03.23 中国经济的宏观形势
2022年之后，国际形势发生了重大变化。过去二十年的经济全球化已经消退，取而代之的是以政治制度&价值观为基础的小团体、彼此割裂对抗，经济增长的共识被政治安全、价值观取代。外部形势的巨大变化，严重影响中国的经济发展策略。
国家施政方针发生重大变化，从战略机遇期的判断、转变为战略机遇与风险挑战并存。在外部环境恶化的情况下，安全取代效率、成为经济发展的首要目标。市场经济要搞国内独立循环圈、跟国际圈并行，重点是产业链独立、科技自主。科技自主，不是追求高精尖的原创，而是要求踏踏实实拿出可用的产品、弥补产业链漏洞。
国家施政政策有明确的定局，包括坚持改革开放应对战略机遇、坚持斗争精神来应对风险挑战。①市场化改革会继续坚持和深入，包括市场导向、对地方放权、减少教条主义等，这根新一届领导班子的经历有很大关系(江浙派)，民营企业会迎来一个较长的宽松期。②政策层面可能会更加保守，市场化改革不会有结构性调整、只会做政策性改良，小修小补更安全；政策对外部内部反馈会高度敏感、更容易出现波动，也是因为政治稳定、经济安全要求。
2021.04.01 云原生时代的Devops
云原生时代，Devops的职能从运维团队、转移到了基础设施(云原生)团队。这加剧了运维岗位的运营化。
职能转移，主要动力在于：K8S体系吸收、囊括了Devops建设思想，使得Devops单独存在的必要性降低。
2021.12.30 云原生运维OPaS
全面云化、云原生化的当下，运维导向调整为OPaS，更关注有形运维服务能力沉淀。有形沉淀包括 规范、流程、平台、架构等，不仅仅限于平台。
云原生体系，将原来比较集中的运维价值，打散到了研发各角色，但依然有部分剩余；OPaS尝试将剩余的运维价值再次集中表述。剩余的运维价值，可能包括非服务视角的应用管理(如业务线粒度的管理和运营)、云资源管理、组件服务管理等。
目前能看到，运维价值被打散的过程还在持续，如云资源管理领域的IaC。OPaS并非抱残守缺、顽固不化，而是为了填补进化过程的空白。甚至，OPaS本身也应该参与到运维价值合理打散的过程中。
2020.08.01 运维产出的思考
运维工作往往融合了 “技术+事务” 两个特色。事务性工作产出制度流程范式，使新人可以按图索骥、并以叠加式改进。技术性工作产出平台设计，以平台的方式沉淀运维能力(最佳实践)。
2020.07.23 做稳定性规划的一些感受
之前一般按照故障处理模型，来做稳定性规划。今年尝试从”对象+方向”双维度来做，效果还不错。一些小的感受如下，
- 预案属于强业务场景，适合按场景闭环、不适合作为一个专项来做
- 容量场景化较弱，适合横向展开。这根涉及容量的场景比较少有关
2020.04.01 传统Ops和SRE主要区别
Ops倾向于被动执行，而SRE倾向于主动思考。
20220713按：Ops和SRE的区别，在于组织、分工、技术架构，很少在于主观能动性。康威定律。