新的一年了，又到了做规划和 OKR 的时候了。作为一个技术团队的管理者，此时除了面对业务的诉求，从技术架构、从团队管理、从未来发展应该做些什么呢？以下是最近一段时间来，个人的思考。从经营的角度来看，研发团队成本对于软件企业来说是成本的大头，作为团队的负责人需要在满足业务需求的前提下，提高研发团队的产出和产出的价值，同时尽量降低过程中的成本，也就是在之前文章中所说的研发价值。这里的研发价值可以具象到研发效能这个概念，在我们做技术规划和 OKR 时，底层思考中的研发效能不仅仅是衡量研发资源使用的效果，更进一步，是指研发团队达成既定目标和结果的能力，换句话说，就是提升当前研发团队的核心竞争力。研发效能不仅包括了技术层面的各种实践，如代码复用、自动化测试、持续集成（CI）和持续交付（CD），还包括了效能度量、流程优化，团队协作、项目管理、需求理解和用户反馈的及时整合等多个方面。研发效能的核心目的是优化交付的价值链，通过提高效能来缩短产品从构思到市场的时间，提升产品质量，降低开发成本，以及增强对市场变化的响应能力。这不仅能提高客户满意度和用户体验，还能为企业带来更大的经济效益和更强的市场竞争力。每个企业，每个团队在做规划时，应该是基于现况，基于客观事实来做规划，明确当下最重要，最需要解决的问题是什么，确认目标，一个个去解决。比如当前大家意识层面有所欠缺，那就想办法拉齐认知「共读一本书」；又或 ...继续阅读 (76)

引子在技术管理者的职业生源中，每一次空降都是一场冒险。无论是谁，一旦从大厂的云端跳伞，降落到充满活力但更为复杂的创业公司，都等同于跨入了一个全新的战场。最近和一个在某创业板新上市公司做过人力资源总监的朋友聊天，有聊到技术高管空降的部分。他分享了三个关于这家公司最近三四年中观察到的三个技术高管的空降过程。这三个技术人在这个过程中挣扎，扎根适应，或者离开。看这三个故事是对看文章的你有所触动？交待一下这家公司的背景：传统行业的新零售，趁着抖音等的火热，其业务从线上到线下，持续火热，于前两年上市创业板，这里分享的是在上市前后入职的三个技术高管的故事。传统零售线上部门研发总监我们的第一位主角是一位年逾四十的研发总监，他是从传统零售茂业百货的线上平台起步，CEO 看中了他为线下传统零售搭建线上零售电商平台的经验。既有传统零售转型的经验，又有足够的管理经验，其跨足到一个新零售公司，以百万+年薪，被公司寄予厚望。优势部门管理经验丰富，有多年的实际技术团队管理经验，快速建立起技术团队技术功底扎实，技术问题基本都能搞定性格不强势和团队能打成一片，兄弟义气，从前公司挖了一些人过来，且能够带领团队攻克难关劣势战略思路及能力差，大多数事情在技术逻辑上业务 sense 和能力不够结果在公司呆了两年多，也把技术团队做得不错，但是老板对其的定位是技术负责人以及线上业务的负责人，其只搞定了技术负责人的角色，没有搞定 ...继续阅读 (75)

SaaS（Software-as-a-Service，软件即服务）概念起源于 1999 年之前，而将这个概念真正实践到商业环境的则是 Salesforce 的总裁马克.贝尼奥夫。在此之前有 SaaS 的先驱 ASP 以失败退场。对比国外至少 40 年的 SaaS 领域的历史，中国到 2015 年才称之为 SaaS 的元年，并且到 2021 年中国企业级 SaaS 的融资事件总数和融资总额也达到一个小高峰。据艾瑞咨询的报告称，2021 年中国企业级 SaaS 市场规模为 728 亿元，宏观经济下行带来了更大的压力，企业 SaaS 总需求收缩将使得行业增速大幅下滑，未来三年 SaaS 行业的增长也将与宏观经济恢复速度相挂钩，在中性预期下，到 2024 年中国企业级 SaaS 市场规模将有望达到 1201 亿元。随着业务的深入和服务经验的积累，部分赛道的 SaaS 产品边界变得愈发模糊，厂商由点及面加速一体化布局，工具型 SaaS 横向渗透并融合特定业务场景来发挥自身价值。在这个赛道创业或工作的技术同学不少，但是技术同学限于技术领域，对于业务的关注较少，在老板、运营同学或产品同学提到 LTV、ARPU、MRR、CAC 等术语时，最开始可能都是一脸蒙，用某个产品大佬的话说，要先拉齐认知，于是有了这篇文章。这篇文章从获客、留存、营收和产品发展阶段等几个方面来梳理一下 SaaS 创业中技术人员 ...继续阅读 (73)

周四下午作为分享嘉宾参加思码逸组织的关于研发效能的技术沙龙，在最后圆桌会议探讨环节，有同学提了一个问题，研发效能是不是一个伪命题？现场回答了下，会后也有持续思考这个问题，基于会后的思考，做一个更完整一些的陈述和总结：从研发效能的定义出发，从背后的逻辑出发，从具体的实践方向出发，来看研发效能这个事情。说到研发效能，大家可能会马上想到度量、指标、流程、CI/CD、代码平台等等东西。但只是这些吗？为什么要做这些？做了这些有什么用？最终的目的是什么？…… 有很多问题冒出来。研发效能是什么看研发效能是什么前我们先看一下效能是什么？效能是一个衡量资源使用的效果的概念，常用于评价在完成一定任务或达成特定目标时资源（如时间、金钱、原料等）的使用效率。效能高意味着用较少的资源投入获得了较多的产出，或者用最优的方式使用资源以达到最佳的工作绩效。在商业和管理领域，效能是指组织或个人在达成既定目标和结果的能力。商业和管理领域中的效能更加注重最终的成果而不仅仅是资源的使用。传统意义上的效能只是商业和管理领域效能的一个过程态，但我们当下所追求还是传统意义上的效能，通过这种效能的不断达成，使得组织的效能增加，从而帮助企业更有效地管理资源，提高组织能力，并在市场竞争中保持优势。回到研发效能是什么，这里我们限定一下范围，主要是软件开发的研发效能，有代码产出的那种研发。对于软件开发来说，主要关注的还是人力成本，或者说 ...继续阅读 (66)

当你成为一个技术团队的管理者时，就会经常会被老板问到，研发的价值在哪里？如何让研发的价值更大？现在的研发团队和行业内相比效率/能力/水平怎么样？如此种种……每个公司每个技术团队的管理者都有自己的逻辑来回答这个问题，因为这是带团队的核心逻辑之一，且各有缘法。今天这篇文章不是想准确的回答这个问题，也不是标准答案，只是这些问题最近引发的一些个人思考。先抛两个公式：公式一：研发的价值 = (业务价值 + 技术价值) – 非正常成本 – 正常成本公式二：研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本这是简化的研发的价值模型，可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整，因为价值的计算可能远比这两个公式复杂。总体来看，让价值更大在于攻守，如何攻，如何守，攻就是提高产出价值，守就是减少成本。在攻的方面，提高产出价值包括提高业务价值和技术价值。我们都知道业务需求是做不完的，如何在做不完的业务需求里面产出更大的价值，关键点在于业务需求本身的价值和业务价值生效的时间，将具有更大价值的业务需求更快的上线是提高研发侧业务价值的主体逻辑。当然，需求上线后可能还有 bug 之类的，这个我们作为守的那部分来聊。提高业务价值提高业务价值的主体逻辑包括两层意思，一个是更大价值的业务需求，另一个是更快的 ...继续阅读 (66)

在当今时代，互联网已成为我们生活中不可或缺的一部分，涉及到日常的方方面面。无论是打车、购物还是社交，我们都依赖于各种应用程序。但是，这些服务一旦出现中断，就可能引起严重的后果。2023 年 11 月份，我们见证了两次重大的网络服务故障：11 月 12 日下午，阿里云服务出现异常，导致依赖其服务的多个厂商及其产品功能受损，包括其自身的产品钉钉。紧接着，11 月 27 日晚，滴滴打车应用程序出现故障，直到 28 日中午才逐渐恢复正常。这次滴滴的服务中断超过了 12 个小时，引起了用户和司机的混乱和不便。就在昨天，12 月 1 日上午，上海医保系统无法进行结算，网友形容「看病一分钟，排队两小时」，凸显了网络服务依赖的脆弱性。特别一点说，滴滴出行在 2023 年 11 月 27 日发生的故障，使我们不得不重新思考我们对系统复杂度的认知。从滴滴的恢复过程中可以看出，系统经历了部分恢复、再次出现问题，数据混乱等现象。整个系统看似处于混乱之中，但在多方努力介入处理后，逐渐恢复稳定并重新运作。这个过程好比一个受伤的系统在逐步疗愈。公众的反应也多种多样，有人归咎于滴滴的「降本增效」策略，有人认为是管理层的失误，还有人指责技术升级不当。但如果把滴滴看作一个整体的系统，它无疑是高度复杂的，由人员、组织结构和各种在线系统组成。这个系统的复杂性在平时可能被我们低估，因为每个人通常只关注自己负责的那部分工作。 ...继续阅读 (81)

你是否也遇到过线上出问题了，查找日志，发现都是 ERROR 日志？你是否也遇到过虽然有日志，但是日志实在太多，在茫茫日志中无法有效地定位到问题？你是否遇到过要去排查前人写的代码产生的 BUG，却还需要把先把相关的代码过一遍，找到相关日志点，再去搜索日志？你是否遇到过日志越来越多，不同的人都在打，有些日志没有用了，还是在不停的打？你是否遇到过奇怪类型的日志，甚至相互冲突以至于无法定位问题？你是否遇到过因为打个日志，导致客户端崩溃？……当日志不在大家的视野中，凭着个人的喜好去打，去定位问题，最终整个日志就会变成一个不断膨胀的怪物，变成大家使用起来都感到困扰和无助的混乱池塘。当日志的生成和使用没有统一的规范和标准，每个人都按照自己的方式和喜好来记录和查找日志，日志的内容和格式就会变得五花八门，导致理解和分析日志的难度大大增加。另外，无效的、重复的、甚至是错误的日志会像野草一样无序地生长，使得日志的数量越来越大，而有效的、有用的日志则可能会被淹没在这个日志的海洋之中。此时，我们需要建立一套有效的日志管理策略，包括设定清晰的日志记录标准，实施有效的日志标准管理，优化日志存储和清理策略等。只有这样，我们才能把这个日志怪物驯化，使得日志成为我们解决问题的有力工具，而不是一种困扰。从过往的经历和上面描述的这些问题里面我们洞察了如下的问题点：日志规范管理的问题日志无序增长的问题日志劣化和无人维护的问 ...继续阅读 (81)

在前面的文章中我们聊了技术成本的精细化运营；聊了要识别出成本要素，找出每个要素的关键成本点，将成本定义为顾客付出的代价，根据成本的基本特性对其分类包括生产性成本、支持性成本、监察成本和浪费成本；聊了成本的核算以及成本和业务以及公司商业化策略的关系等等。今天我们从一个技术团队的负责人角度来聊一下软件研发过程中的成本。研发过程中成本主要包括研发过程的成本和对业务产生的影响而带来的「非正常成本」。而其中软件研发成本的核心是认知成本和沟通成本。认知成本认知成本是一个相对宽泛的概念，它涉及到所有获取、理解、处理信息以及进行决策的努力和资源。在一般情况下，认知成本可以分为以下几个部分：学习成本：这是指为了掌握新的知识、技能或工具所需要的时间和精力。如一个开发同学需要学习一种新的编程语言，那么这就会产生学习成本。理解成本：这是指为了理解新的信息或知识所需要的时间和精力。如阅读和理解一份复杂的技术方案文档就会产生理解成本。处理成本：这是指为了处理信息，比如进行分析、整理或应用，所需要的时间和精力。如分析一份用户行为数据报告就会产生处理成本。决策成本：这是指为了做出决策，比如评估选项、权衡利弊、制定策略，所需要的时间和精力。如选择一个软件开发框架或选择一个市场策略就会产生决策成本。在实际应用中，降低认知成本通常是提高效率和效果的重要目标。例如，良好的用户界面设计可以降低用户的认知成本，提高用户体验； ...继续阅读 (72)

一个技术团队管理者在带团队过程中常常要「通过别人的手拿到结果」，常常要主动去改变一些事情，去完成一些公司或上级的要求，甚至要自己去做一些事情……仔细回顾一下，有没有出现你的上级绕过你直接找你的下属来处理问题，而你一无所知，只有出了问题的时候才知道？有没有出现你发起了一个事情，任务已经交给下属/其它同事来跟进处理了，到截止时间，结果和你想象中的不一样？有没有出现你实在忍不住，亲自动手把那块代码写了，一边写还一边吐槽，也就十几分钟的事儿，跟他讲的时间都已经上线了……如此种种，是不是很是亲切，经常会遇到。这到底是哪里出问题了呢？如果把这些事项都当作一个项目来看的，这些项目中有三个主要角色：发起人（Sponsor）、负责人（Project Manager）和核心成员（Core Team Members）。上面的这些问题大多数是角色错位，职责分工不明确或者项目成员本身对于自己所在角色的认知不清晰导致的。今天我们就聊聊这三个角色，以及经常会出现的问题。发起人（Sponsor）发起人是项目的发起者，他们通常是公司的高级领导人或决策者，有权利和资源来推动项目的实施。他们的主要职责和特点包括：确定项目的战略目标，并向所有相关方清晰地传达这些目标，一般不参与具体任务。提供必要的资源和资金以支持项目的实施。对项目有最终兜底责任，在必要时提供对项目的支持，解决可能对项目产生影响的问题和挑战。监督项目的进度 ...继续阅读 (88)

在 10 月 23 日，语雀服务出现了一次重大故障，中断时间超过 7 小时。具体来说，这次故障的起因是在执行系统升级操作期间，新的运维升级工具出现了 bug，导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧，无法直接将其上线，这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作，但由于数据量大，恢复方案有限，恢复过程耗时 4 小时，数据检验耗时耗时 2 小时。这次故障给用户带来了严重的影响，也让我们重新审视关于本次故障带来的思考。我将整个复盘报告输入给到 chatGPT，其给我的回复如下：从语雀的这次事故中，我们可以学到以下几个关键的教训：重视运维工具的测试和质量保证：在这次事故中，新的运维升级工具的 bug 是导致故障的主要原因。这说明，即使是运维工具，也需要进行足够的测试和质量保证。在实际使用之前，应该在相似的环境中进行充分的测试，确保其稳定性和安全性。灾备和恢复系统的重要性：即使有了数据备份，恢复仍然可能需要花费大量时间，这会导致服务中断时间过长。因此，除了定期备份数据外，还需要建立有效的灾备和恢复系统，以便在灾难发生时，能够快速恢复服务。灾难恢复演练的必要性：定期的灾难恢复演练可以帮助我们在真实的灾难发生时，更快地恢复服务。通过演练，我们可以发现并解决恢复过程中可能存在的问题，提高恢复的效率。高可用架构的重要性：高可用架构可以保证在部分 ...继续阅读 (76)

我们经常会发现工作中会出现很多重点项目，很多事情忽然就来了，问就是老板需求，却没有一个过程来告诉大家前因后果和价值。这往往会导致大家感到迷茫，因为没有获得足够的信息和时间来理解和准备这些项目。这个过程从项目管理的角度来说是缺少立项，而立项往往是最容易被忽视的。当没有明确的立项过程时，目标模糊、资源浪费、沟通困难、出现项目风险等问题都会时有发生，从而影响整个项目的实施效果和公司的业务发展。1 什么是立项立项是一个组织或公司决定开始一个新项目时的决策过程，这个过程涵盖了对项目需求的明确、项目目标的设定、可行性的评估、资源的分配和风险的识别及管理等关键步骤。通过立项过程，组织能确保每个项目有明确的目标、适当的资源分配、风险控制措施以及一个清晰的执行计划，从而提高项目的成功率和效率。立项的本质是一个综合的决策过程，其中项目的各干系方对目标、方案、成本、风险和里程碑等重要预期进行对齐，以便做出是否启动项目并如何分配资源的决定。2 立项的作用立项就像是给项目开个「导航」，帮助我们明确要去的目的地，规划好路线，分配好需要的人和物，预防可能的风险，确认能否按计划到达，并让所有人都了解这个「旅行计划」，以提高我们的旅行效率和成功率。具体一些，包含以下六个作用：明确目标：立项过程有助于明确项目的目标和期望结果，使所有参与者对项目的方向和目标有共同的理解。如我们在开发一个新的移动应用的立项过程中，项目组 ...继续阅读 (82)

对于一个 SaaS 来说，隔离是一个非常重要的技术架构策略。当隔离的策略和业务不匹配的时候，往往可能会引发一些线上事故/问题，影响性能等等。隔离的意义在于创建独立、安全的运行环境，以保护数据的私密性、保证服务的稳定性，并防止资源的竞争和滥用，从而为每个客户提供高质量且可靠的服务。隔离的本质隔离的本质在于实现独立性和安全性，通过这两者，为每个客户提供一个能够有效，安全使用共享资源的环境。独立性: 隔离确保每个租户都有其自己的资源（如CPU时间、内存空间、磁盘空间等），数据，运行环境和网络通信，且这些都是互不干扰的。这使得每个租户都能在其自己的独立环境中运行，无需担心受到其他租户的影响。安全性: 隔离也保护每个租户的数据，防止其数据被其他租户访问或修改。此外，隔离还能限制每个租户的操作权限，使其只能执行一些安全的操作，以防止其执行可能影响其他租户或整个系统安全的操作。但是现实中我们往往做不到完全的独立性和安全性，需要根据实际的业务情况确定架构，从而有了不同层面的隔离策略。我们在实际工作中，对于隔离策略能感受到的最直接的影响是：一个良好的隔离策略可以在一定程度上改善服务的稳定性，减少因为某些不可预知的突发事件导致的线上问题影响范围。隔离是一件系统工程，我们从其应用层面和基于租户的落地策略来看这个事情。隔离策略的应用层面隔离策略可以应用在多个层面，并且从落地的位置来看，可以分为以下几个层： ...继续阅读 (76)

在我们的工作中经常会看到各种类型的指标，如营收指标、技术指标、效能指标等等，细化下来有年营收金额、SLA、千行代码缺陷率等等。这些指标量化着我们的工作和目标，让我们朝着目标前进，如果指标有问题，也会导致走偏，或者为了指标而玩数字游戏。当迷惑于指标，或者指标有问题的时候，需要停下来思考一下：指标是什么，可以分为几类？指标有什么价值？指标是如何生成的？制定指标的过程中有什么讲究？如何评判一个指标的好处？跟进指标的过程中有什么注意点？对指标进行复盘时要看哪些点？指标是什么指标的本质是一种衡量工具，它提供了一个客观的、定量的方法来评价某个特定的目标或过程的性能或结果。换句话说，指标是把抽象的目标或过程转化为可以衡量和跟踪的具体数值，是一个由虚转实的工具。指标的设计和选择必须反映出我们所关注的核心问题和目标。比如，如果我们的目标是提高产品质量，那么我们需要的指标可能包括产品缺陷率，客户满意度等。同时，指标也是一种沟通工具。它们可以帮助团队成员理解目标，以及衡量他们的工作是否有助于实现这些目标。当所有人都清楚地知道他们的工作如何对公司的总体目标产生影响时，他们可能会更积极地参与和投入。总的来说，指标的本质是将目标和过程量化，以便于衡量和沟通，从而推动团队或组织向预定的目标前进。从价值的角度来看，指标在企业管理和决策中发挥着重要的作用：提供信息和见解：指标能够提供实时的、可量化的信息，帮助企业了 ...继续阅读 (78)

在我们的工作中会遇到很多问题，也会有人来问我们问题，对于问题，我们可能会选择直接解决，或者 @ 某个人来解决，或者 @ 好几个人来解决。如果一个问题是交到我们这里来解决，尽量成为问题解决者。成为问题解决者成为问题的解决者意味着什么？对于技术管理者来说，意味着我们要负责任地处理问题，去解决问题，而不是转发，一定是要对问题本身有认知，有判断后再去处理，再去解决，而不是简单地将问题转发给其他人。这就要求我们深入全面的了解问题的背景和现状，分析问题的根源和可能的解决方案；这就要求我们具备批判性思维、解决问题的能力，以及对我们负责的业务领域和技术领域有深入的理解。也意味着技术管理者要对他的决策和行动负责。我们不仅要解决当前的问题，还要预防未来可能出现的问题，有前瞻性的思维，能够预见可能出现的问题，并提前做好准备。对于一线开发同学来说，意味着我们要负责任地处理问题，去解决问题，而不是转发，不是简单地把问题推给其他人，需要负责任并主动的去寻找解决方案。这需要我们深化对问题的理解，探索可能的解决方案，然后付诸行动。这不仅要求我们具备强大的技术能力，也要求我们有独立思考和解决问题的能力。在面对问题时，我们不应该急于求成，而应该耐心分析，找出问题的根源。这可能需要我们查阅相关文档和资料，或者利用调试工具进行深入地分析。我们必须理解问题的本质，以便找出最有效的解决方案，可能最终只是改一个配置或一行代码。 ...继续阅读 (75)

作为一名技术管理者，面对日常工作中的各种问题和挑战，我们需要具备出色的问题解决能力。技术团队管理本身就是一项充满挑战的任务，而解决问题的能力更是推动团队向前的关键。当一个技术管理者拥有极强的解决问题的能力后，他大概能应对挑战、降低风险、提高团队绩效、增强领导力并提升个人职业发展。在解决问题的过程中，我们可以将问题分为三个层次。了解这三个层次将帮助我们更好地应对不同场景下的问题，成为更优秀的技术管理者。1 应急响应类应急响应类问题的处理是通过快速反应和短期改进措施来修复问题的反应性流程。其主要作用是停止损害，防止蔓延。应急响应通常是一种反应式行为，并不研究根本性的问题以及背后的原因。应急响应不会导致理想状态的实现，但是仍然可以满足即时需求、保护客户，为更加深入地挖掘和调查重要细节赢得宝贵时间。有效的应急响应有助于企业产品获得更好的稳定性。应急响应类问题涉及到系统或产品出现紧急故障时，需要立即采取行动以避免进一步影响。这种解决方式专注于快速应对问题，暂时稳定状况，但可能不会深入探讨问题的根本原因。例如，服务器宕机导致网站无法访问，技术管理者需要立即组织团队快速评估问题的严重性，制定并实施紧急应对措施，进行故障排查，找出问题根源并进行修复，以保障系统正常运行。针对此类问题，常规处理流程如下：确认问题：在故障发生时，第一步是确认问题的具体表现和影响范围。快速定位：尽快找到故障发生的关键环节 ...继续阅读 (61)

1 为什么会有异地团队当一个企业成长到一定程度后，往往会在多地建立研发中心或者业务中心，这里企业的考量可能会有如下的一些点：人才资源：不同的城市和地区可能具有独特的人才资源，通过在多个城市建立研发中心，公司可以吸引和招聘到更多具有不同技能和背景的优秀人才。这有助于公司在保持竞争力，并确保能够获取到足够的人才来支持研发和业务需求。比如深圳是中国的高新技术产业中心，其在硬件制造、消费电子、通信技术等方面具有很强的竞争力，对硬件制造、物联网、人工智能等领域拥有丰富经验的工程师较多，并且由于深圳地理位置优越，靠近香港，拥有国际化的人才环境，因此在跨境项目和多元文化沟通方面具备优势；又如北京是中国的政治、文化和教育中心，拥有众多顶级高校和研究机构，拥有大量理论研究和技术创新方面的顶尖人才，北京的互联网行业较为成熟，尤其是在互联网+政务、在线教育、大数据等方面有较多经验的人才。市场覆盖：在多个城市设立研发中心有助于公司更好地了解和适应不同地区的市场需求。这可以让公司更迅速地响应市场变化，提供更符合客户需求的产品和服务。成本优化：不同地区的劳动力成本、房地产成本和生活成本可能存在差异。在多个城市建立研发中心可以让公司充分利用各地的成本优势，降低整体运营成本。如一些深圳/北京的公司，会把一些研发中心放到西安、成都、武汉、长沙等城市。政策支持：一些城市为了吸引优秀企业入驻，可能会提供各种政策支持，如 ...继续阅读 (74)

GPT-4 于 2023 年 3 月 14 日发布。目前 GPT-4 没有免费版本，仅向 ChatGPT Plus 的付费订阅用户及企业和开发者开放。如比尔盖茨在 reddit 回答网友提问时回答时说的：「AI is the big one. I don’t think Web3 was that big or that metaverse stuff alone was revolutionary but AI is quite revolutionary」，我们可能又到了一个历史性的转折点。现在各家企业，包括 Google、微软，以及国内的 BAT 等大厂都在大量投入，一些中小厂也在垂直的应用赛道拔城攻寨，作为一个技术管理者一定会面对这样一个洪流，在洪流之中我们需要注意什么呢？如果你所在企业要上线 AIGC 的产品，或者已经上线 AIGC 的产品，以下的五个重要事项需要特别注意。1 安全安全是产品的生命线，特别是对于 AIGC 产品来说，没有安全守护，不仅仅是产品玩完，甚至会连累其它产品甚至公司存续。1.1 内容安全这里内容安全的定义是指 AIGC 生成内容影响产品本身存在的领域。在国内与内容安全相关的场景包括涉政、色情、性感（性感和色情在内容安全中是不一样的）、暴恐、违禁、恶心、涉价值观等。其中每一项都需要检测，部分项出现问题甚至会关站和约谈。在 chatGPT 大火后，网络 ...继续阅读 (75)

在看文章之前先思考两个问题：人和人的差别究竟在哪？人和人之间为什么会有差别？在各种场合我们经常听到这样一句话：「听懂了很多道理，却依然过不好这一生」。 这里有两个逻辑，一个是知行合一的逻辑，另一个是人的成长在于是否超越了昨天的自己。今天我们聊一聊作为一个技术管理者应该要有的 4 种基本思维：掌控者思维、杠杆思维，终局思维，闭环思维掌控者思维在聊掌控者思维之前我们先看一下掌控者思维的反面：受害者思维。受害者思维又称为弱者思维，有受害者思维的人在任何时候都会把自己当作一个受害者或弱者，极端者会把整个世界都投射为「伤害者」，「都是别人不对，都是别人对不起我」。受害者思维是一种思维定势，其本质上是一种忽视自己的主观能动性的行为。在《乡村爱情 13》里面，王木生是老总儿子，富二代，但是干啥啥不行，还总是给自己找借口，说大环境不好，其他没这背景的都比他强。赵本山饰演的他爹王大拿就教训他：「自己没能力就说没能力，怎么你到哪，哪都大环境不好，咋，你是破坏大环境的人啊？」这就是比较明显的受害者思维，也就是我们常说的「甩锅」。 受害者思维不仅仅只有这一种表现，在《拆掉思维里的墙》里面，作者总结了 5 种受害者思维的表现。推卸责任，保住面子： 上面王木生就是明显的例子，还有像一些网上的评论说的「便秘都怪地球没引力」都是类似的表现。在这种情况下，受害者思维就会认为自己没有责任，不需要承担责任，相信地球没引 ...继续阅读 (66)

在我们聊企业级 SaaS 产品稳定性之前我们先定义一下这里的企业级 SaaS 产品是什么，稳定性是什么。1. 企业级 SaaS 产品根据各家研报的定义，企业级 SaaS 是指以企业客户为服务对象，通过 SaaS 交付模式，向企业用户提供管理软件的服务。主要具有网络供应，集中托管、按需供应及服务化四大特征。网络供应是指 SaaS 产品大多部署在云端，每个客户使用产品的方式，通过互联网进行分发；集中托管是指使用「多租户构架（Multi-Tenant）」，依靠对数据库分区/分表（其中的一种实现方式）来实现隔离操作，逻辑上隔离，物理层面是共享的。对私有化部署的客户，会单独处理；按需供应是针对中小企业的需求，中小企业的需求在短时间内有较大幅度的变化，特别是一些快速增长的发展类企业；服务化是指 SaaS 企业按月/年付费的商业模式，其核心的增长逻辑在于持续服务的能力，这也是 SaaS 企业的核心竞争力，第一次交付产品只是整个客户生命周期的起点。以上 4 个特征可以让客户享有开箱即用、较低成本、实时更新以及按需订阅的优点。1.1 SaaS 产品和 C 端产品的区别SaaS 端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽象、角色、权限等问题。除了使用者本身的功能需求以外，还需要考虑管理者或者决策者的管理需求。C 端产品面临的场景相对单一，并且使用者是相对独立的单个用户，因 ...继续阅读 (60)

上次我们聊到了技术成本的精细化运营，有点干，今天我们再聊一点不那么干的，聊一下做这个事情背后的逻辑。企业存在的目的是在外部、市场上和经济体中创造成果，企业内部只有成本。在德鲁克的《成果管理》中提到成本时说「大多数企业的年度降低成本热潮总会像春季的伤风感冒一样如期而至，往往 6 个月过后，成本又恢复到原有水平，企业又开始为下一轮降低成本运动做准备」。感觉确实是这么个节奏，当你的成本控制有一定成效后，你会发现成长慢慢又开始涨了，而且还是那种特别有理由的，不得不涨。不管是控制成本还是做其它事情，一些做事的方式变化不会太大，如要有重点，如要一事一议，如要有大局观，我们控制成本有如下原则：先处理大头的成本或者先控制能产生更大效果的成本点，特别是大的原则；不同类别的成本要用不同的策略对待，如生产性成本考虑其投入产出比，监察类成本考虑不做会怎样，带来的成本是多少？最有效的降本方式是把某块直接去掉，减少比不上直接清零，评估确实去掉会更好的可以直接干掉；要有大局观，不能一个地方成本降低了，另一个地方成本增加了，不能这个月成本低了，但是整体成本却高了，有时我们可以容忍这个月成本高一些，接下来的成本低，总体成本低一些。在控制成本的过程中，要能识别出成本要素，找出每个要素的关键成本点，将成本定义为顾客付出的代价，根据成本的基本特性对其分类，输出成本诊断报告。在诊断成本时，主要成本可以分为：生产性成本，是企 ...继续阅读 (59)

在技术团队的日常管理工作中，一个管理者做得最多的事情是决策、开会，最不想看到的是线上事故，线上事故给技术团队带来非常大的冲击，而给线上系统带来风险最大的研发环节是线上环境的变更，甚至有人说：「没有变更就没有问题」，对此我们不置可否，但这些变更之所以会导致事故，从根源上来讲大部分是技术同学犯了错。这里的决策、会议，变更，错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的，今天我们就来聊聊这 4 个基本认知。1 决策在带团队的过程中我们会做非常多的决策，如去决策是否投入足够大量的人力满足某个业务，或者升级架构，或者构建某个流程机制等等。这些决策中从服务于时间维分为两种：当下的决策，如评估需求优先级，先做什么，后做什么，关注的是当下和已有的；未来的决策，如评估技术架构演进、团队演化和发展等等，关注的是未来。当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。对于产品需求，技术管理者的作用是把价值不高，或者没有价值的需求干掉，不让其进入研发，不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题：为什么会有这个需求？一般是想看这个需求是怎么来的，用户故事是怎样的；这个需求的价值是什么？一般是想看这个需求做了之后对产品或业务的好处，看产出；如何度量这些价值？一般是想通过数据看到需求的价值，把价值反馈在指标上，如营收 ...继续阅读 (67)

降本增率是今年的主旋律，对于技术团队来说，最大的成本除了人力成本，就是我们的技术成本。这里的技术成本包括各种 CDN、网络带宽、服务器、存储、云计算服务等。如果你是一个运维总监，或者是技术负责人，需要在技术成本上节流提效，这篇文章应该对你有一些帮助。今天所讲的策略是当我们面对一个已有的技术基建和系统，如何有计划地针对技术成本做优化，如何持续运营，让成本降下来，让钱花得有理有据。整体分为两个阶段，成本优化和精细化运营1 成本优化成本优化是一个「止血」的过程，如果之前没有刻意关注过技术成本，可能存在较多的浪费或者不合理，特别是当业务在高速野蛮发展的时期，一不留神就会出现你想象不到的成本浪费。我们做成本优化一般有如下几步：1.1 组建团队一件事情要想做得比较好，得先有一个团队。对于技术成本优化这种可能会跨团队，跨业务的事情，更需要有一个合适的团队。在项目成立时，我们可以成立专项小组，小组由以下成员角色组成：Owner(组长/负责人)：负责整个项目的规划、计划安排、人员协调以及对外沟通汇报等，为整个项目负责；运维的负责人（运维总监/ SRE 负责人）：负责整体技术成本的评估、公共技术成本的评估、优化，以及云服务商上相关操作的评估，规划和人员安排， Owner 和运维的负责人可以是同一个人；业务侧的技术负责人（各业务的技术总监/技术经理）：负责各业务侧技术成本的评估、优化落地；财务的负责人（ ...继续阅读 (62)

1. 跨端架构的意义在《The Pragmatic Programmer》（中文翻译为《程序员修炼之道》）中，作者提了一个 DRY(Don’t Repeat Yourself)原则，主要指在程序设计以及计算中避免重复代码，因为这样会降低灵活性、简洁性。 把一切重复的代码抽象出来复用，当需要修改的时候只需要修改一次。 这里的复用有如下一些级别：函数级复用、对象级复用、模块级复用、类库级复用、框架级复用。 咱们今天聊的跨端是更高层面的复用，是端的复用。现实中我们常见的工作方式是安卓的同学写安卓，iOS 的同学写 iOS，前端写 Web，小程序，H5 等等。 随着整体技术的进步，前端技术的发展，大前端的兴起，跨端实现越来多了，一些跨端的框架层出不穷。最终想要实现的跨端架构希望能做到：一次编写，多端运行这里的端包括如下：PC 端(苹果，Windows、Linux)移动端（安卓、iOS)Web 应用、插件小程序（微信小程序，企业微信小程序、钉钉小程序、快手小程序）H5以上跨端的逻辑分为三个层面硬件形态，或者说是设备，如 PC 电脑，移动设备、物联网设备相同硬件形态下的不同平台，或者说是跨操作系统，如 PC 下的 Mac、Windows相同平台下不同的应用或应用中的衍生应用，如 iOS 平台下浏览器应用（H5），微信小程序，支付宝小程序等应用运行在某个操作系统之上，操作系统位于硬件 ...继续阅读 (60)

说起测试左移，得从瀑布模型开始。软件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 发表于 1970 年的著名文章 “Managing the Developmentof Large Software Systems” (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。虽然这个模型可能是个误会，可以见 Craig Larman 和 Victor Basili 教授在 2003 年发表于 IEEE Computer 杂志的封面文章《Iterative and Incremental Development: A Brief History》中为我们讲解了一段非常精彩的有关瀑布模型的历史故事，这也可以说是世界软件工程史最大的误解之一。他其实一直倡导的是迭代、递增和演进式开发，他在那篇文章中描述的瀑布模型其实只是一种最简单的情况，并不是普遍适用的，现在看也不是一种先进、最佳的方案。瀑布模型的生命周期，包括需求分析阶段、设计阶段、实现阶段和测试阶段等等，其中测试又可以分为单元测试、功能测试、系统集成测试等。测试左移是在瀑布模型的基础上，为弥补瀑布模型的不足，不让测试工作只成为产品交付前的最后一道屏障，而将测试往前提，将测试贯穿于整个软件研发生命周期中。这里为什么是左移呢，是因为我们大多数的阅读习惯是从左 ...继续阅读 (58)

技术团队管理者在日常工作中可能经常会遇到如下一些状况：自测质量差转测 BUG 多项目延期加班赶工高强度加班后，小伙伴状态不好，导致更多的问题出现从第 1 点状况演变成第 5 种状况，第 5 点状况继续推动第 1 种状态的持续加强，从而导致整个团队的状态极差，陷入 BUG 多 –> 延期 –> 加班 –> BUG 更多 –> 更多的延期 的死循环。除了上面的死循环，可能还会有一些非功能性的问题，如性能、扩展性问题等等。当团队大时，还可能遇到有小团队，各小团队各行其事，各为其主，心不往一处，力不出一孔。 这些问题让技术团队的管理者焦头烂额。那么如何解决这些问题呢？个人认为可以从以下 4 个方面来逐一思考和优化，从而在一定程度上解决这些问题。1. 把正确的人放到合适的岗位所有的执行最终都是落到人身上，有了正确的人，事情会事半功倍。 说到人，我们往往会提起人的「选用育留」，这是一个很大的题目，我们不做详细的讲述，只关注选和用的一小部分。管理上有一个在大部分场景适用的套路：选拔优先于培养。 这个套路背后有两层逻辑：改变一个人太难，比如有些人就是懒，抽一鞭子动一下；又或者家境优渥，态度佛系，无欲无求，根本就是油盐不进；又或者玻璃心，安全感差，都很难搞；成本太高，即使这个人具备可培养性，但从 0 到 1 把一个人培养起来，时间成本太高，而管理者的时间很贵，公司等不起。所以我们这里是选人，从现有的 ...继续阅读 (64)

在《汉语词典》中，沟通有如下定义：沟通本指开沟以使两水相通。后用以泛指使两方相通连，也指疏通彼此的意见。沟通是通过一定的载体将思想、信息和情感在人与人之间进行传递或交换的过程，群体间的沟通最终也会落到人身上。 著名组织管理学家巴纳德认为「沟通是把一个组织中的成员联系在一起，以实现共同目标的手段」，没有沟通，就没有管理。沟通不良几乎是每个企业都存在的问题，企业的机构越是复杂，层级越多，其沟通就越发困难。 一线的许多意见在上传过程中，被层层过滤掉了；高层的决策传达，在落到一线同学时可能表述完全不一样了。 沟通在组织中的主要作用是上传下达，相互协调，以维系组织存在，保持和加强组织纽带，创造和维护组织文化，提高组织效率。1 沟通的基本组成沟通由四个要素组成：沟通目的、沟通对象、沟通内容和沟通方式。这四个要素是相辅相成的关系，缺一不可。这四个要素回答了四个问题，为什么要沟通；和谁沟通；沟通什么；怎么沟通。沟通目的：是指沟通开始前需要弄清楚沟通的目标是什么，任何沟通都需要有一个目标，如果没有目标，也就不需要沟通了。沟通对象：明确需要沟通的对象是谁，背景，身份，角色等等，在《官场现形记》第 38 回：“第二要嘴巴会说，见人说人话，见鬼说鬼话，见了官场说官场上的话，见了生意人说生意场中的话。”，这也是明确沟通对象，根据沟通对象确认后续的沟通方式。沟通内容：是指在沟通中出现的内容，包括思想、信息和情 ...继续阅读 (54)

在互联网软件企业，今年是一个大家都在非常努力降本增效的年份，包括且不限于人员优化、人员结构优化、技术成本优化，提高人效，提升研发效能等等。 这篇文章我们从研发效能出发，尝试梳理一下打造高效能研发团队的 5 个关键步骤：目标、流程、团队、个人、度量。1. 找到正确的目标技术最终都是通过业务产生价值，就算是技术类的产品，最终产生价值也是业务，只是这个业务是一个强技术属性的业务。一个高效能的研发团队管理者，其首要任务是为团队找到正确的方向和目标。这里正确的目标可以分为业务目标和技术目标。业务目标的设定可以分为两步：和业务方、上级沟通，弄清楚他们的目标是什么，以及明确他们对于研发团队的预期是什么；在业务方目标和上级预期目标的基础上，分解目标，内化为带有一定进取的团队目标。技术目标的设定可以分为两类：解决过去留下来的问题，历史的问题我们通常称之为技术债，技术债分为主动债务和被动任务，主动债务大多数是在业务发展过程中为了追求速度而做的一种技术妥协，而被动债务大多数是团队能力或水平不足、业务的演化或技术的发展导致的代码或架构劣化任务，或者不再适用于当下的环境。技术债不一定是一个坏事，一个产品进化到要偿还技术债时，说明业务应该还不错了，在这个当下，找准时机，有计划的偿还一些技术债务是非常有必要的事情。解决将来可能出现的问题，将来的问题我们一般称为技术前瞻性，即对即将出现或已经出现但不是很成熟的技术 ...继续阅读 (56)

前一篇我们聊了优先级，以有限应对无限，今天再聊一聊经常会用到优先级的决策。记得我刚开始带团队的时候，有位前辈和我说过，管理就是收集信息，做出决策。 这里的决策就是我们今天要聊的内容。一个组织最有限且不可再生的资源是什么，就是成员的工作时间。 对于一个互联网企业或软件企业来说，人力成本是最大的成本。 而作为一个技术团队的管理者，其最大的作用是如何让研发同学的时间能产生最大的价值，也就是如何让这些成本的 ROI 最高。 为了提高 ROI 的时，我们经常要做出决策。那么什么是决策？在说决策之前，我们先说一下决定，决策和决定是不同的。 在各种会上，或者平常的工作中，我们会做各种各样的决定，用哪种架构，做哪个流程或者用哪种方案等等。 只有这些决定产生了资源的分配，才是真正的决定，否则就只能算是一个「伪决定」，或者说根本没有改变什么，也就没有真正的决定什么。 上面所说的资源不仅仅是实体的资源，还有组织中最有限且不可再生的资源：组织成员的工作时间。一个决定通常具备三个特征:有要达到的目标 —— 没有目标，任何决定都无所谓有选择或者说有不同的可选方案 —— 没有选择就没有决定可做；资源是有限的 —— 资源如果是无限的，我们就可以做任何我们想做的事，而不需要做选择。综上所述，决定就是选择最好（最合适）的方案，以有限的资源达成目的，其本质是资源的分配。那么决策是什么，决策和决定是什么关系？决策是关乎未 ...继续阅读 (60)

一个互联网产品的生命周期大概可以分为需求阶段，研发阶段，运营阶段。 在需求阶段，通常我们会有需求优先级； 在研发阶段，会有转测 BUG 等级，BUG 的严重程度； 在运营阶段，会有线上 BUG 等级，线上事故等级。为什么会有等级或者优先级？其背后的根本原因是资源是有限的。在有限的资源内，如何更好地完成需求，修复线上问题，处理线上事故是我们在研发管理过程中要反复面对的问题。 而这个要反复面对的问题，业内通用的解决方式是定优先级，也就是我们常说的 P0，P1……1. 需求优先级需求优先级，指产品需求的优先级，哪些需求先做，哪些需求后做，哪些需求不做，其关注的是业务价值或者要解决问题的价值。需求优先级一般有 3 个，P0，P1，P2 在资源有限的前提下，P0 是必须要做的，P1 是在 P0 做完后有空余人力可以去做，P2 现阶段基本可以不做。当业务方问为啥我们：“这个需求没有咋没有排上，我都提了这么久了，你们是怎么评估优先级的？” 我们需要有一些相对客观的逻辑或方法来回复业务方。需求的评估可以分两步：第一步：从需求的角度来看，任何一个需求一定服务于某个战略 / 某个目标 / 某个场景，需要根据其服务的目标来做第一次的优先级评估。如果是服务于战略，根据战略的级别和影响范围来评估，比如是公司级的战略项目优先级肯定要高一些；如果是服务于某个目标，这里的目标可能是合同或者营收，根据合同的金额，合 ...继续阅读 (54)

对于一个互联网创业公司来说，其生存所依赖的业务系统每天都会产生大量的日志，比如系统日志、业务流水日志、程序异常日志、访问日志、审计日志等等。通过收集业务日志数据，供离线和在线的分析系统使用，以支持线上业务或运营分析等使用。日志除了供分析系统使用以外，更多的时候开发同学会依赖日志排查问题。当我们需要使用到日志排查问题时，它们往往是我们手上唯一可以用来查明当时的发生状况和问题的根本原因的有用信息，并且在开发过程中，我们也会使用日志查看程序运行时的状态。日志系统三部分关于日志，分为三部分：打日志 打日志可以分为客户端日志和服务端日志，这两种日志都会包含日志的基本功能，排查问题、查看运行时状态和供分析系统使用；收集日志 当日志打在客户端，或打在分布式的服务器时，就需要将这些分散在各地的日志收集回来；分析日志 当从日志中心下载到日志后，根据实际的需求我们需要分析日志，可能是给分析系统、告警系统或者业务系统使用，又或者是直接给到开发同学确认排查问题等等。打日志日志分级按 RFC5424 的标准，日志级别分为八个级别，分别是：0 Emergency 紧急：系统已不可用1 Alert 警报：必须立即采取措施2 Critical 关键：临界条件3 Error 错误：错误条件4 Warning 警告：警告状况，系统能继续运行5 Notice 注意：正常但重要的条件6 Informational 信息： ...继续阅读 (50)