技术管理者应有的 4 种基本思维模式

在看文章之前先思考两个问题:

  • 人和人的差别究竟在哪?
  • 人和人之间为什么会有差别?

在各种场合我们经常听到这样一句话:「听懂了很多道理,却依然过不好这一生」。 这里有两个逻辑,一个是知行合一的逻辑,另一个是人的成长在于是否超越了昨天的自己。

今天我们聊一聊作为一个技术管理者应该要有的 4 种基本思维:掌控者思维、杠杆思维,终局思维,闭环思维

掌控者思维

在聊掌控者思维之前我们先看一下掌控者思维的反面:受害者思维。

受害者思维又称为弱者思维,有受害者思维的人在任何时候都会把自己当作一个受害者或弱者,极端者会把整个世界都投射为「伤害者」,「都是别人不对,都是别人对不起我」。

受害者思维是一种思维定势,其本质上是一种忽视自己的主观能动性的行为。

在《乡村爱情 13》里面,王木生是老总儿子,富二代,但是干啥啥不行,还总是给自己找借口,说大环境不好,其他没这背景的都比他强。赵本山饰演的他爹王大拿就教训他:「自己没能力就说没能力,怎么你到哪,哪都大环境不好,咋,你是破坏大环境的人啊?」

这就是比较明显的受害者思维,也就是我们常说的「甩锅」。 受害者思维不仅仅只有这一种表现,在《拆掉思维里的墙》里面,作者总结了 5 种受害者思维的表现。

  1. 推卸责任,保住面子: 上面王木生就是明显的例子,还有像一些网上的评论说的「便秘都怪地球没引力」都是类似的表现。在这种情况下,受害者思维就会认为自己没有责任,不需要承担责任,相信地球没引力,相信大环境不好……
  2. 安心做坏事:这种表现就是为自己的行为找到一个自洽的逻辑,让自己有一个完美的故事,从而在做坏事的时候能心安理得。比如 2001 被判死刑的「杀人魔头张君」(实施团伙抢劫,犯故意杀人罪 2 2次,致 28 人死亡、22 人重伤)在 2001.4.17 一审审理结束后对公众说的话:「我还要向没有枪的受害者和你们的家庭说声‘对不起’,现在想起来,以前有些事情确实做错了,但我没办法,因为我要生存。」
  3. 让我们一起分享凄惨故事会:寻找同伴,和他们分享你的受害过程,在他们那里得到安慰。比如有个女孩失恋了,她的闺蜜会陪她喝酒,说男人没有一个好东西;
  4. 用受害获得同情和帮助:第 4 种和第 3 种有些类似,其区别是上面是通过群体得到安慰,得到是一种情感或者心理上的安慰,而这种是更直接的帮助或者说利益,如我们在职场里面看到的一些人会假装自己不会,从而让热心的同事帮忙解决,自己偷懒,或者在路上我们看到的一些乞丐,可能他们的收入比你想象中多很多;
  5. 自我伤害,绑架他人:这种就更极端了,生活中常见于情侣分手,某一方说,你要是离开我,我就自杀,或者电视剧中的男主站在女主楼下淋雨以求得原谅或者求得表白成功。

如此种种,这些可以让你有短暂的快乐和安全感,但是慢慢就会失去自信、勇气以及自我改进的能力,就会真的变成一个受害者,一个弱者。

我们活在这个尘世,很多事情已经无法掌握,如古罗马哲学家爱比克泰德(Epictetus, 约55~约135年)所说:「我们登上的并非我们所选择的舞台,演出并非我们所选择的剧本」,如果连我们自己也无法掌控,让自己的快乐、成功都掌控在别人手里,这会是怎样一个光景呢?

当你带一个技术团队的时候,当你的团队遇到问题的时候,当你的下属遇到他认为过不去的坎的时候,当发生线上事故的时候,当老板怼到脸上的时候,你会怎么办呢?

当一个受害者吗?是大环境不好?是技术太难?还是坏人太多?

不,绝对不是这样,一个技术管理者应该是强于面对现实,敢于直面问题,像汪涵在我是歌手第三季总决赛面对大型事故时所说的那样:「没事儿不惹事,事儿来了也不要怕事」,以一种掌控的状态来扛起事情,解决问题。

这就是我们所说的掌控者思维,一种强者思维,一种充分发挥自己主观能动性的行为。

掌控者思维的核心思考是:「如果把所有经历过的事情重新倒推一遍,所有条件都不改变,只有自己改变,你能否得到一个更好的结果呢

掌控者思维是从责任心,自我成长,主动改变等方面来提升一个技术管理者的修养,以达到自我的精进。 并且不管什么情况,你都可以负全责。只要你愿意,你就可以做得更好。

除了不怕事,负起责任,还有一些是我们必须要做的。

  1. 学习,提升自己的认知,把自己从知道自己不知道变成知道自己知道,换句话说,保持有计划的学习;
  2. 自省,持续的自省,比如当你有一件事做得不好,自我反思一下哪里做得不好,下一次如何改进,或者更深入一些读一些相关的系统的书,写一篇文章或文档来复盘,掌控自己,从卷自己开始;
  3. 计划,凡事预则立,不预则废,如下棋一般,走一步,算三步,把事情想在前头,如美国首席数据科学家 DJ Patil 所说流传很广的那个便签上的话:「Dream in Years. Plan in Months Evaluate in Weeks. Ship Daily. 」
  4. 知行合一,只有做到,才是真的知道。

当然,做一个掌控者会累一些,但是与自由相比,累又算得了什么呢?

杠杆思维

阿基米德说:「给我一个支点,我就能撬起整个地球。」。

一个优秀的人,都有「杠杆思维」,懂得利用杠杆原理,以较小的付出,撬动更大的回报。这里我们所要说的是杠杆思维中的团队杠杆。

当我们从一个开发变成一个技术管理者时,就不再是一个人在战斗了,你的主要责任就不再是写好代码,而是「使众人行」。

时间对于每个人都是公平的,一个人一天都有 24 小时,它是有限的,而我们所面对的这个世界,工作这些都是无限的。

在一个健康经营的互联网企业中,需求也是无限的,而开发同学的时间都是有限的,除了优先级,我们还能做什么呢?此时有人会说:加人啊。是的,加人。但是加人不是随便加的,他有一个底层逻辑,这个就是今天我们要说的团队杠杆。

团队杠杆的本质是叠加效率,人的时间是有限的,而事情是无限的。

什么是团队杠杆?

通过团队,团队的管理者确定好方向,通过良好的机制和人才梯队,系统化成功的路径,叠加个体的优势,创造出远超个人贡献总和的价值,让 1+1>2,这就是团队杠杆。

既然是杠杆,就一定有一个支点,咱们的支点是什么呢?

对一个团队来说,其支点是已经达成了共识的目标和价值观。

目标是什么,是方向,是团队成员能看到的远方。

为什么是达成了共识?是因为只有达成了共识才能保证目标的统一,才能有意愿,有内在的动力去做事情,才能起到杠杆的效果。

目标和价值观只是最基础的,对于一个团队来说,不同的时候其支点也会不同。

  • 在野蛮生长的团队中,核心岗位上的同学的能力提升是主要支点,这里的核心岗位上的能力提升有两层意思,一个是培养员工,给他们训练的机会,培训,从而快速成长;另一个层面是考虑换一个人,当你这认为这个岗位上的员工的能力、态度差不多到顶了,那就可以考虑用更好、更合适的人来替换,这里的逻辑是选拔大于培养
  • 在快速扩张的团队中,流程和效率是主要支点,通过流程提升协同的效率,通过流程让新人快速融入团队;
  • 在稳定发展的团队中,标准和系统是主要支点,当业务趋于稳定,通过标准和系统固化操作,以系统代码流程和人工。

有了支点,我们就需要开始寻找杠杆,对于一个技术团队来说,团队的杠杆有多大,由人决定。 一个团队里面的人是怎样的,人才梯队是怎样的,人才密度是怎样的?

像麦肯锡,每年都会从全球各个顶尖大学,比如哈佛大学、斯坦福大学、麻省理工学院等,招一大批刚毕业的年轻人,不管是不是商学院毕业的。这些绝顶聪明的年轻人,就是麦肯锡充沛而有效的「团队杠杆」。

对于我们一个普通的互联网创业公司来说,作为一个技术团队的负责人,在有限的范围内选出符合要求的同学,同时尽我所能的带好团队。对于如何来带好团队,我们可以从如下 4 个大的方面来

  1. 信任:不管是平级,还是上下级,信任是必须品,通过良好的沟通,多次的合作,一起的奋斗达成信任,这样才是一个好的团队;
  2. 习惯:管理者以身作则培养团队良好的工作习惯,如做事闭环,分级处理,不越红线等等;
  3. 标准:制定能落地的标准,让大家知道什么是好的,什么是对的;
  4. 能力:流程机制决定事情的下限,人才梯队和个人能力决定事情的上限,管理者要帮忙团队成员成长,发现他们的短板,坦率的沟通并提出改进期望,提升成员的技能,以达成更好的结果。

以上带好团队的表述有些虚,但是是这么个逻辑,各团队各公司术法不同,但方向一致。

用好团队杠杆,一个人走得更快,一群人走得更远。

终局思维

什么是终局思维?

所谓终局思维,是指从终点或者未来的某个时间节点出发,回看现在所做选择,并进行推演的一种思考模式。

这里可能有人会问,什么是终局,是否有终局?这就有点哲学的味道了,先假定有吧,至少在某个未来的时间段是会有一个确定的终局。

我们经常听到人们感叹,如果这辈子能够再来一回,很多错误就不会犯,很多人也不会错过,这算是终局思维的一种表现。只是这个终局思维是等到了终局再提起,有些晚了,我们可以再早一些。

我们在做一件事情的时候,如果能思考一下这件事情的最终达成的目标,或者把最终的形态在脑海里面勾画出来,以终为始,站在未来看当下,修正当下正在做的事情,那么这件事情成功的概率可能就不一样了。

终局思维有 4 个核心点:

  1. 认清方向,所谓的终局思维,一定是你要知道终局是什么,一定要有目标有方向;
  2. 拉长时间周期看问题,在一个较长时间维里来反复推演的逻辑;
  3. 从历史或者更宏观的层面看问题,不局限于当下,不局限于眼前的一亩三分地,把视野拉到历史长河等更大的层面;
  4. 反推机制,终局思维中非常重要的点,从未来反向推演现在要做什么,或者从现在推演未来怎样。

终局思维有什么用?

当一个企业的老板大概知道了未来是什么样子,又能不断地判断和复盘自己的能力,他自然就有了非常强的战略驱动能力,也非常敢为未来投资。

当一个技术管理者知道了团队未来是怎么样的,又能反思当前的情况,从未来形态反思当下的状态,他自然就知道现在最重要的是做什么。

当一个开发同学知道了自己在职场上想成为什么样的人,又能反思自己提升自己,他自然知道现在应该做什么,应该学什么,应该选择什么样的团队,什么样的路。

但是,这里一定会有一个痛苦的过程,甚至不止一个,可能是一直在痛苦中,折腾自己,反思自己,提升自己,一直有危机感,一直在学习中。

心理学研究说,人类对于外部世界的认识可分为三个区域:舒适区(comfort zone),学习区(stretch zone),和恐慌区(stress zone)。我们反思自己、提升自己的过程基本都是在学习区,人只有在学习区的时候,才会是进步的时候。

闭环思维

经常听到人人说:「凡事有交代,件件有着落,事事有回音」,这是典型的闭环思维,是一个职场人的必备思维。作为一个技术管理者更应该具备闭环思维,因为这将是你带团队的核心逻辑之一,它强调责任、敏感性和团队协作,是使众人行的必备。

以「逆向」的逻辑来推演一下,假设你带的团队成员都具备闭环思维,将是什么样的场景?

  • 高效率:闭环思维要求在一定时间内,无论任务完成的效果如何,都要认真、负责的反馈给发起人。这可以帮助团队及时发现问题并加以解决,从而提高工作效率。
  • 强协作:闭环思维需要团队成员之间相互配合,洞察干系人每个阶段的需求,并在截止期内给对方反馈。这可以增强团队协作,提高团队的工作效率和成果。
  • 靠谱:闭环思维要求做事靠谱,做事清楚明白,不会出现意外差错,就算出了问题也会提前告知,让对方可以启用方案 B。这样的技术团队会让人觉得可靠和可信,提高团队在公司中的信任度。
  • 好形象:闭环思维是一种良好的职业素养,可以让你和你的团队建立良好的职业形象。在职场中,「闭环思维」不仅仅说明了一个员工拥有完成任务的能力,还体现出「良好的合作意识」,这样的你会让上级、兄弟部门觉得很「靠谱」,能够放心的将工作交给你和你的团队。

那么如何做到闭环思维呢?

闭环思维有两层逻辑,一个是完整,即有完整的闭环,做事情的时候需要考虑事情的起点、目标、影响因素和结果,明确需求和关键点,以及可能遇到的问题,在过程中设置检查点,让事情可控;另一个是主动反馈,在我们完成一项工作或参加一项事情,不管执行效果如何,都要及时将结果反馈给发起人。

第一层逻辑我们可以使用 PDCA 环来辅助达成,第二层反馈逻辑还是需要刻意去练习,甚至给自己设置一些任务提醒来达到反馈的目的,并且在反馈时尽量做到 STAR 的表述。

番外

最近 chatGPT 一直在火,于是就今天的题目我问了 chatGPT 一些问题:

  • 技术管理者必备的4种基本思维模式
  • 技术管理者必备的思维模式
  • 技术管理的四种思维
  • 技术管理者必备的4种思维

大概的答案如下:

openAI 的回答

问:技术管理者必备的思维模式

作为一名技术管理者,以下是一些必备的思维模式:

  1. 系统思维模式:技术管理者需要具备系统思维模式,能够理解和处理复杂系统的各种关系和相互作用,从而在整个系统中发现问题并提供解决方案。
  2. 创新思维模式:技术管理者需要能够持续地推动创新,寻找新的解决方案并将其应用到业务中,从而实现业务目标。
  3. 问题解决思维模式:技术管理者需要能够分析和解决各种问题,包括技术问题、组织问题和人员问题等。
  4. 客户导向思维模式:技术管理者需要关注客户需求和体验,从客户的角度出发思考问题,为客户提供高质量的产品和服务。
  5. 团队合作思维模式:技术管理者需要具备团队合作意识,能够有效地管理和领导团队,激发员工的潜力,协调各种资源,实现业务目标。
  6. 风险管理思维模式:技术管理者需要对业务中可能出现的风险进行预测和管理,制定相应的应对措施,确保业务的可持续发展。
  7. 数据驱动思维模式:技术管理者需要依据数据进行决策和管理,从数据中发现问题和机会,制定相应的战略和计划,提高业务效率和效果。
  8. 学习和成长思维模式:技术管理者需要保持学习和成长的态度,不断学习新知识和技能,从他人的经验中汲取营养,不断提高自身的领导能力和管理水平。

phind 的回答

问:技术管理者必备的4种基本思维模式

答案1

作为技术管理者,必备的4种基本思维模式如下:

  1. 系统思维:技术管理者需要具备系统思维,可以将复杂的问题分解为简单的部分,然后逐一解决。例如,当公司需要开发一个新产品时,技术管理者需要思考每个阶段的具体步骤,确定每个步骤的时间表和责任人,确保整个过程的顺利进行。
  2. 创新思维:技术管理者需要具备创新思维,可以在技术方面寻找新的解决方案,以提高公司的竞争力。例如,当公司需要开发一项新技术时,技术管理者需要思考如何利用现有技术来开发出更好的产品,或者如何开发出全新的技术来满足市场需求。
  3. 沟通思维:技术管理者需要具备良好的沟通能力,可以与员工、客户和其他部门进行有效的沟通。例如,当公司需要与客户沟通产品需求时,技术管理者需要了解客户的需求,并将这些需求传达给开发团队。
  4. 领导思维:技术管理者需要具备领导思维,可以激励员工,推动项目进展,达成公司目标。例如,当公司需要完成一个重要项目时,技术管理者需要领导开发团队,确保项目按时完成,并向管理层报告项目进展情况。

技术管理者不仅需要具备以上4种基本思维模式,还需要具备自我驱动、架构把握、目标管理等核心能力,才能胜任管理岗位。在实际工作中,技术管理者应该灵活运用这些思维模式和能力,不断提升自己的管理水平。

答案 2

根据多个来源,以下是技术管理必备的四种思维和其他相关思维模型:

  1. 抽象思维:这种思维能力可以帮助技术人快速抽取面对问题的关键要素和本质,从而更好地分析和解决问题。
  2. 系统思维:这种思维能力可以帮助技术人将问题看作一个整体,理解各个组成部分之间的相互作用和影响,从而更好地进行系统设计和管理。
  3. 创新思维:这种思维能力可以帮助技术人寻找新的解决方案和创新点,从而更好地推动技术进步和发展。
  4. 逻辑思维:这种思维能力可以帮助技术人分析和推理问题,从而更好地发现问题根源和解决方案。

除了以上四种思维,以下是其他常用的思维模型:

  • PEST分析:这是一种常用的管理咨询框架,可以帮助企业从政治、经济、社会和技术等多个角度分析市场环境和竞争对手,从而更好地制定战略和决策。
  • PDCA循环:这是一种管理模型,可以帮助企业进行持续改进和优化,包括计划、执行、检查和行动四个环节。
  • SMART原则:这是一种目标管理模型,可以帮助企业制定具体、可衡量、可达成、有意义和时限的目标,从而更好地推动业务发展。
  • STAR法:这是一种面试技巧,可以帮助面试者回答问题更具体、更有条理、更有说服力,包括情境(situation)、任务(task)、行动(action)和结果(result)四个要素。
  • 5W2H法:这是一种问题分析和解决模型,可以帮助企业和个人从五个W(what、why、who、when、where)和两个H(how、how much)多个角度分析问题和制定解决方案。
  • PERT 技术:这是一种项目管理工具,可以帮助企业规划和安排整个项目行程,跟踪实施阶段,从而更好地控制项目进度和成本。

总之,技术管理必备的思维能力和模型是多种多样的,需要根据具体情况选择和应用。除了上述思维能力和模型外,还有很多其他的思维工具和技术,需要技术人员不断学习和掌握,以更好

答案 3

根据多个来源的信息,以下是四种技术管理必备的思维能力:

  1. 抽象思维:这种思维能力可以帮助技术人员快速抽取问题的关键要素和本质,从而更快地理解问题和解决问题。例如,当面对一个新的编程语言时,抽象思维可以帮助技术人员快速理解其核心概念和语法规则。
  2. 产品思维:这种思维能力可以帮助技术人员更好地理解用户需求,并将技术解决方案转化为实际的产品。例如,一个架构师需要了解产品的功能需求,以便设计出最佳的技术架构来支持这些需求。
  3. 创新思维:这种思维能力可以帮助技术人员不断创新,寻找新的解决方案和技术。例如,当面对一个复杂的技术问题时,创新思维可以帮助技术人员找到一种独特的解决方案,从而提高效率和质量。
  4. 商业思维:这种思维能力可以帮助技术人员更好地理解商业环境和商业需求,以便为企业提供最佳的技术支持和解决方案。例如,在设计一个新的软件系统时,商业思维可以帮助技术人员理解客户的商业需求,并设计出最佳的系统架构来支持这些需求。

除了以上四种思维能力外,还有其他常见的思维模型和方法可以帮助技术人员更好地管理和解决问题,例如:

  • PDCA 循环:这是一种常见的问题解决方法,包括计划、实施、检查和行动四个阶段,可以帮助技术人员系统地解决问题。
  • SMART 原则:这是一种有效的目标设定方法,包括具体、可衡量、可实现、相关和时间限制五个要素,可以帮助技术人员设定清晰的目标和指标。
  • 5W2H 法:这是一种问题分析方法,包括什么、为什么、谁、何时、何地、如何和多少七个问题,可以帮助技术人员全面地分析和解决问题。
作者:潘锦
链接:https://juejin.cn/post/7203880677195661373
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

聊聊企业级 SaaS 产品稳定性

在我们聊企业级 SaaS 产品稳定性之前我们先定义一下这里的企业级 SaaS 产品是什么,稳定性是什么。

1. 企业级 SaaS 产品

根据各家研报的定义,企业级 SaaS 是指以企业客户为服务对象,通过 SaaS 交付模式,向企业用户提供管理软件的服务。主要具有网络供应,集中托管、按需供应及服务化四大特征。

  • 网络供应 是指 SaaS 产品大多部署在云端,每个客户使用产品的方式,通过互联网进行分发;
  • 集中托管 是指使用「多租户构架(Multi-Tenant)」,依靠对数据库分区/分表(其中的一种实现方式)来实现隔离操作,逻辑上隔离,物理层面是共享的。对私有化部署的客户,会单独处理;
  • 按需供应 是针对中小企业的需求,中小企业的需求在短时间内有较大幅度的变化,特别是一些快速增长的发展类企业;
  • 服务化 是指 SaaS 企业按月/年付费的商业模式,其核心的增长逻辑在于持续服务的能力,这也是 SaaS 企业的核心竞争力,第一次交付产品只是整个客户生命周期的起点。

以上 4 个特征可以让客户享有开箱即用、较低成本、实时更新以及按需订阅的优点。

1.1 SaaS 产品和 C 端产品的区别

SaaS 端产品面临复杂的业务场景和用户场景,因此进行细节设计时,必须关注建模、抽象、角色、权限等问题。除了使用者本身的功能需求以外,还需要考虑管理者或者决策者的管理需求。C 端产品面临的场景相对单一,并且使用者是相对独立的单个用户,因此不用关心角色、权限管理,而要关注用户的体验,需要在交互设计上投入很大精力。除此之外,在付费决策、使用场景、专业度的期待值、安全等方面都有不同:

  • 付费决策人不同,C 端产品的使用者和决策者基本重合,而 SaaS 产品的决策者和使用者绝大部分可能是不同的两波人;
  • SaaS 产品绝大部分在工作场景,而 C 端产品大部分在生活或娱乐场景;
  • SaaS 产品关注功能 > 体验,需要能帮助他解决工作场景里面的问题,体验反而是其次;
  • SaaS 客户花了钱,对稳定性要求会更高,对于问题的容忍度会变低,甚至有些要求会写到合同中去,当出现可用性问题时会有赔偿的情况;
  • SaaS 客户对于专业服务的期待值不同,他们对于问题希望是有更专业的人员和更专业的方式来解决,如包括专业的服务,专业的产品,专业的流程,专业的人员,专业的交付,专业的客情维护和沟通话术;
  • SaaS 客户对于产品安全、数据隐私、隔离等方面有更高的要求;
  • SaaS 产品交付只是整个客户生命周期的起点,核心的增长逻辑在于持续服务的能力;
  • SaaS 客户更看重服务过程中 SaaS 企业的专业表现。

1.2 隔离性

以隔离性为例,企业级 SaaS 产品对于隔离性的要求也不一样,我们看一下 AWS 对于隔离性有更细致的要求,总结起来有如下 3 点:

  1. 隔离不是可选项,是产品的基本要素,系统需要确保有解决方案来提供隔离性;
  2. 身份验证和权限管理不等于隔离,它只是隔离的一个环节,在这个环节后面需要构建对于开发人员视野之外的隔离策略,并作为默认项;
  3. 隔离不等于要求完全的物理隔离,可以基于共享资源模型的多租户逻辑,对于有特殊要求的可以提供物理资源级别的隔离。

思考一下,为什么会有隔离性的需求

SaaS 服务往往会服务于多家企业,企业与企业之间的数据需要完全隔离,不同的企业其量级,需求各有差别,当一家企业使用出问题时不能影响另外一家企业,比如某个企业触发了一个 BUG,这个 BUG 不能影响别的企业的使用,或者一家企业的数据量特别大,不能因为家企业的数据计算影响别家企业的计算,特别是有一些离线计算逻辑的时候。我们在使用云服务的时候也会遇到宿主机超卖的问题,这其实也是一种隔离性做得不到位的情况。

以上这些是我们了解到的一些关于 SaaS 企业的定义和特性。

做产品稳定性的建设和我们平时做一个需求一样,先要搞清楚需求方是谁,需求的价值是什么。

企业级 SaaS 的稳定性需求来自于哪里,是行业,政府,还是客户,还是公司要求?

比如金融行业,有一些业务模块对于稳定性的要求来自于政府,是不能打折扣的,做不好,可能会影响公司生死。又比如在内容相关的行业,如果对于一些涉政、涉黄等内容没能控制住,任其泛滥,可能会导致产品的下架,这里的要求同样来自于行业和政府。

回到我们企业级 SaaS 产品的稳定性,这个需求来自于购买了我们服务的客户,SaaS 产品解决的是工作中的问题,是生产资料的一种,当生产资料不可用的时候会对其工作产生破坏,比如依赖于某个数据分析系统的结论,但是数据分析不能用了,老板要求的报告就出不来,此时又不可能重新拉数据分析,只能等,这样可能就会影响用户第二天的的汇报工作等等,后果可能是丢了客户,甚至丢了工作。如果我们长期不稳定,稳定性也将会影响公司的生死。

相对于 C 端用户的数据,SaaS 的数据显得尤为重要,其作为企业资产的一部分,具有有形的价值,甚至是企业的核心资产,比如做代码管理的 SaaS 服务,对于一家软件公司来说,代码就是其核心的资产,如果因为 SaaS 服务数据丢失,或者泄漏,对于企业来说将会是影响企业生死的大事故。

2. 产品稳定性

前面更多的是聊需求和需求价值,接下来我们聊一下产品稳定性具体是指什么,以及如何做好产品稳定性。

产品稳定性包括三个方面:产品功能的稳定性、数据的稳定性和系统服务的稳定性。

2.1 产品功能的稳定性

产品功能的稳定性可以从功能的上线、变更和下线三个方面来看。无论怎样,我们在做产品功能的变更时都是以减少打扰用户为前提。

2.1.1 产品功能的上线

产品功能的上线,在上线每个功能的时候都要慎重,想不清楚宁可不做,在我们习惯了互联网的敏捷模式后,快速迭代,快速试错成为我们常规的工作方法,但是对于 SaaS 产品来说,敏捷不再是最重要的点。

对于我们的客户来说,更重要的是解决一个场景的问题,或者说解决他们工作中的问题,能提升效率。在我们上线一个产品功能的时候应该能讲出用户故事。

当有某个产品功能能够解决用户问题后,就不要经易改变其逻辑,因为用户已经可能将这个产品功能做到了工作的 SOP 里面。

2.1.2 产品功能的变更

产品功能的变更包括产品的版本规划、功能发布变更。

对于产品功能的规划或版本管理,需要有特定的节奏,让用户习惯你的节奏。对于每个版本,做好了,做稳了,把版本发布前前后后的事情做扎实了再慢慢发布出去,给客户一个接受的过程,一个较轻的落地。并且能让客户能快速找到变更了什么,给客户安全感,如 Saleforce 有一个发布说明(R)https://help.salesforce.com/s/articleView?id=release-notes.salesforce_release_notes.htm&type=5&release=240

有节奏的发版,比如 Canvas LMS(一个学习管理平台) 是每个月的每三个星期六正式发版(Release),每周的周三灰度部署(Deploy),用户可选择性预览使用灰度部署的功能 canvas release

又如 Salesforce 一年就三个版本,命名为 Spring, Summer,Winter spring-22-release 这里不仅仅是发版,发版只是技术层面的逻辑,这里的更多的是产品的逻辑,需求左移。

2.1.3 产品功能的下线

产品功能下线,在下线的时候要考虑到如何承接这部分用户的需求,尽量能有替代方案来承接。

变更管理没有银弹,我们能做的是控制节奏,以 SaaS 的逻辑来控制变更管理,这里的管理除了代码的发布,还有线上环境的变更,线上配置的变更等等,强调一点:在用户的使用期间,不要动任何线上的东西,包括代码,配置,环境等,一切以不影响用户工作为前提。

当产品功能变更,或者进行大版本升级时充分考虑用户的操作习惯以及学习成本,可能你面对的用户在电脑上学会一个操作是很难的一件事情,甚至需要有人专门来培训。每一次的产品变更就需要其培训负责的同学从头来培训一遍。

就算用户量少,也要进行灰度,减少影响范围

2.2 数据的稳定性

数据的稳定性是企业级 SaaS 产品特别重要的一点,只有确保客户数据的安全性才能长久提供服务,其主要包括以下 4 点:

  • 数据不会乱,主要是指当用户习惯了一些数据的逻辑后,不要轻易的打乱,如一些默认排序规则,一些分类逻辑之类的;
  • 数据不会丢,数据备份,长期存储,对于上传的文件,在满足成本要求的基础上,尽可能的存下来,如果实在不能存了,也放一个地方,给用户一个出口可以方便获取得到;
  • 数据不会泄漏,这块是数据安全的范围,比较常见的问题是不同的租户数据串了,或者不同的用户数据串了,这里原因可能是代码问题或者架构问题。还有更严重如我们在网上经常看到的被拖库,如前段时间上海的数据泄漏
  • 数据可追溯,对于用户的操作,有详细的日志,知道数据从哪来的,要到哪去的,当出了问题可以追溯。

2.3 系统服务的稳定性

系统的稳定性包括系统的可用性和性能稳定:

2.3.1 系统的可用性

系统的可用性指在一个给定的时间间隔内,对于产品系统来说,总的可用时间所占的比例。我们一般用 SLA(Service-level Agreement) 约束和描述可用性,其常用指标如下:

  • MTBF:Mean Time Between Failure,平均故障间隔时间
  • MTTR:Mean Time To Repair,平均恢复前时间
  • MTTF:Mean Time To Failure,修复前平均时间

关于可用性,所要做的事情太多,简单几个字,可用性治理就包括了度量、线上管控、架构治理和研发管理等等。

在互联网行业有个对于线上事故 「 1-5-10 」的原则,即 1 分钟发现,5 分钟定位,10 分钟恢复,如果能做到这个程度,算是及格了。而且这只是针对可用性线上事故处理 SOP 中的一个逻辑,我们要做的事情还有很多。

落到常规建设中,监控、压测和演练,三个经常要做的操作,但是实际上我们仅仅关注了监控的一部分及压测的一部分。

关于系统可用性我们可以做如下一些关键的步骤:

  • 测试并跟踪当前的可用性:先有度量,诊断我们可用性的状态;
  • 将手动流程自动化,自动化部署过程:相信代码比人更靠谱,特别是针对重复性事务;
  • 维护和跟踪管理系统中的所有配置:所有和线上相关的都是线上环境,而线上配置的变更往往是高危风险地带;
  • 构建线上问题的快速恢复能力:包括但不限于灰度发布、A/B 实验环境,允许快速更改并进行实验,并且保证如果出现了问题可以轻松回滚;
  • 将线上问题和系统可用性作为技术团队的核心绩效指标:管理逻辑中有一个核心点你考核什么,大伙儿就会注重什么,人多数是趋利的;
  • 以不断改进应用程序和系统为目标:反脆弱、不能因为怕变更带来的风险而停止改进;
  • 服务分级,制定严格的 on-call 机制,对于核心服务需要在分钟级响应并处理。

2.3.2 系统的性能稳定

系统的性能稳定指在满足用户功能可用的基础上,稳定性能,同时在一定程度上帮助可用性的建设。

稳定性和可用性相比,除了关注系统可以无故障地持续运行时间,故障发生的频率,还会关注性能劣化趋势等等。稳定性更关注系统在给定条件下的响应是否一致,行为是否稳定。稳定是对可用性的进一步的要求。

上面聊完了企业级 SaaS 产品和产品稳定性,接下来我们聊聊如何长久的做稳定性的治理,如董宇辉老师在直播间谈到初恋时说的:「你不就图我吗?更长久的图我吗?我懂」,对于稳定性我们也是想长久的图。而且还是用科学的方法系统来图。

3 基于风险模型的稳定性治理

考虑到稳定性治理是一个长期的事情,且是需要持续迭代的,如果只是靠人来推动,当人员变动或者工作重点变化时,可能稳定性相关的事情就会陷入停滞状态。

此时我们可以把所有的稳定性问题抽象出来,形成风险,我们通过系统性的持续的识别风险,并制定对应的风险缓解计划和应对计划,应该是可以较好的控制整个系统的稳定性情况。

管理风险的第一步是识别并理解系统中已有的风险。识别、标记并对已知的风险排列优先级,这就是风险模型所要做的事情。

尽管我们总是想消除风险,但是这样做的成本通常是无法接受的,无论是从实际成本还是从机会成本的角度来看都是如此。我们肯定有更重要、更加需要以客户为中心的事情要做,这些事情对我们的客户、公司来说都有好处,而不是从应用程序中消除你所知道的每一个风险。

管理风险涉及对每个风险评估两个值:风险的可能性和风险的严重性。一般来说,严重性是风险发生时的成本,而可能性是风险发生的概率。一个不太可能发生但是会对应用程序造成非常严重影响的风险,不一定是你想要消除的风险。同样,一个很可能发生但是对应用程序影响很小的风险,也不一定是你想要优先消除的风险。但是,一个很可能会发生并且会导致严重影响的问题,是你需要优先解决的风险。

3.1 风险管理

在聊风险模型之前,我们先聊一下风险管理。

风险管理(Risk Management)是指如何在项目或者企业一个肯定有风险的环境里把风险减至最低的管理过程。风险管理是指通过对风险的认识、衡量和分析,选择最有效的方式,主动地、有目的地、有计划地处理风险,以最小成本争取获得最大安全保证的管理方法。

从系统开发的角度看,风险管理包括系统中的风险的位置,确定哪些风险必须消除,哪些风险可以暂时存在,以及如何降低这些留存风险发生的可能性和重要性。

风险主要由可能性和严重性两方面组成:

  • 严重性:如果风险发生,所需付出的代价
  • 可能性:风险发生的概率

管理风险就是要管理这两个方面。

3.2 风险模型

风险模型是风险管理的第一步:理解系统中已有的风险,识别、标记并对已知的风险排列优先级,最终形成一张包含了系统所有已知风险的当前状态的表格。这就是我们所说的风险模型。

建立风险模型的过程是识别风险的过程,在这个过程中我们需要识别出系统中已有的风险,并对其进行分析,标记出优先级、梳理当前状态和历史情况。

风险模型构建过程中需要考虑模型的作用范围,是公司级的,团队级的,项目组的,还是服务级的。

对于一个小公司,可以是公司级的,对于大型一些的公司,可以考虑团队或项目级的。

风险模型至少包括以下一些方面:

  • 严重性/可能性:高中低,先评估严重性,再评估可能性
  • 风险缓和计划:可以使用的或者正在使用的用来降低该风险严重性或者可能性的风险缓和措施。
  • 监控:对该风险的发生是否进行了监控,如果监控了说明监控的指标,如果没有监控,说明原因,以及达成监控目标的原因,最终所有的风险应该是要监控起来的。
  • 状态:活跃 / 已缓和 /  正在修复 / 已解决
  • 历史风险情况:该风险在历史上有没有发生过,什么时候,发生频率等
  • 风险缓和计划:当我们制定风险缓和计划的时候,需要从严重性最高的项开始,缓和风险不是为了消除,而是为了降低风险的严重性和可能性。并不是每一个风险都要制订风险缓和计划。
  • 风险预案:当风险发生的时候,我们可以采取的措施

除此之外,还包括一些常规的添加时间,ID,负责人之类的

3.3 识别风险

我们参照如上风险模型的项,通过头脑风暴等方式构建整个风险模型,在过程中可以考虑从如下的一些点中提取风险点:

  • 已知的故障
  • 有出现的告警
  • 用户支持的反馈
  • 可能存在的性能问题,或者一些慢 SQL 等
  • 服务间的强弱依赖
  • 一些功能的缺失
  • 服务单点
  • 内部和外部/离线和在线业务的相互影响
  • 服务容量的不足
  • 基建发布或扩容等发布操作会影响业务的情况
  • 线上配置/环境/网络等的变更
  • 安全问题
  • 系统或流程的问题,如没有文档,没有沉淀,只在某些人的脑袋里面
  • 一些已知的,明确的技术债务

基于上面的逻辑,我们梳理后可以得到一个风险列表,我们称之为风险模型。

3.4 风险缓和计划

风险模型中的风险缓和计划用来说明可以进行或者正在进行哪些风险缓和措施,来降低当前风险的严重性、可能性。这里我们不需要完全消除风险,只是降低风险发生的可能性和严重性。

常见的风险缓和计划,我们一些常见的降级策略属于风险缓和计划的主要部分,包括但不限于:

  • 前端降级:应对后端服务不可用或后端服务异常等风险;
  • 缓存降级:应对存储不可用或下游服务不可用等风险;
  • 主备切换:应对主存储不可用等风险;
  • 业务隔离:应对多业务接入时,单个业务引起的整体服务不可用的风险;
  • 应用限流:应对多业务接入时,单个业务引起的整体服务不可用的风险;
  • 整体限流:应对大流量突发的风险,保障部分用户可用;
  • 容量评估及提前扩容:应对大流量突发的风险,保障一定程度流量下的业务稳定性;
  • 全链路压测:应对整体链接容量不一致的风险,防止单点容量风险;
  • 线上问题及用户反馈清理:应对系统中小的风险引起的大风险,如一些系统 BUG,一些没有测出来的问题等等;
  • 线上告警及时处理:应对系统中小的风险引起的大风险,如一些系统 BUG;
  • 扩缩容演练:应对容量冲击时基建没有准备好的风险;
  • 定期压测及容量评估:应对系统演化过程中,代码变更,模块变更导致的容量变化;
  • 性能优化:应对系统中某些服务的性能问题导致的风险;

以上的一些策略只是缓和了部分风险,像容量的风险,BUG 的风险,不可用的风险不可能完全消除,只能缓和,以降低风险发生的可能性,或者降低风险发生时的严重性。

基于以上的一些思路,我们需要做一些专项和一些机制来保证风险可控。

但风险之所以为风险,是说明他还是有可能发生的,当发生时我们需要做什么呢,这就是我们接下来要准备的预案。

当风险发生时,我们计划如何来处理,这个计划是我们有预先设计的,是一个系统性的计划。

比如,当容量突发时,开启降级策略或者限流策略等等。

3.5 定期风险回顾,维护风险模型

风险模型是稳定性治理过程的抓手,通过不停的识别风险,消除风险,缓和风险,不断提高稳定性变好的可能,以最终达到稳定性的目标。

风险评估和应对规划是一个反复重复的过程,不停的迭代风险模型,识别出新的风险。

当风险模型构建完成后,我们需要定期逐个风险拉出来 review 一次,我们可以问我们自己如下的一些问题:

  • 与上次回顾相比,风险有更严重吗?可能性有更高吗?
  • 接下来会排专人来解决某些风险吗?是否应该安排?
  • 上次回顾安排的事项落实了,对应的风险情况如何,是否有更新到风险模型中?

问完问题,我们可能需要有一些实际的行动:

  • 评估是否有新的风险;
  • 删除旧的风险:如果风险已经解决了,可以归档;
  • 评估原有风险模型中的每一项风险,评估其严重性和可能性,如果有变动,对其进行更新;
  • 对于不同的优先级的风险区别对待。

以上的回顾操作我们建议以某个管理系统来承载,并且这个管理系统是带有通知等功能,以更好的将风险相关的信息周知出去,如 Jira 系统。

写在最后

记得当年「我是歌王」有一段汪涵救场的主持,从一个观众的角度看,真的牛逼,简直是教科书式,这算是一个超大的线上事故,但是这和我们的稳定性有什么关系呢,我们有如下的思考点:

  1. 为什么会有这个事故发生 – 问原因
  2. 在流程和机制上是否有改进的空间来规避 – 如何系统性的规避
  3. 这个事故有没有其它更平滑的处理方案,减少对用户的影响 – 如何减少影响
  4. 我们是否需要英雄 – 线上不应该有英雄

如同扁鹊的大哥一样:「长兄于病视神,未有形而除之,故名不出于家」

最后有一些原则可以指导我们稳定性的工作:

  1. 以用户为中心,不打扰,不影响
  2. 灰度,产品灰度,发布灰度,坚持住
  3. 防微杜渐,敬畏线上
  4. 快速发现,快速解决,减少对于用户的影响

重复一句:我们所做的一切都是以减少对客户的打扰为前提。

在我们所有的事项中并没有写与组织结构、人才梯队相关的内容,并不是这些不需要,恰恰相关,他们至关重要。下次有机会我们再聊。

最后,祝大家新年快乐~

再聊一下技术成本

上次我们聊到了技术成本的精细化运营,有点干,今天我们再聊一点不那么干的,聊一下做这个事情背后的逻辑。

企业存在的目的是在外部、市场上和经济体中创造成果,企业内部只有成本。

在德鲁克的《成果管理》中提到成本时说「大多数企业的年度降低成本热潮总会像春季的伤风感冒一样如期而至,往往 6 个月过后,成本又恢复到原有水平,企业又开始为下一轮降低成本运动做准备」。感觉确实是这么个节奏,当你的成本控制有一定成效后,你会发现成长慢慢又开始涨了,而且还是那种特别有理由的,不得不涨。

不管是控制成本还是做其它事情,一些做事的方式变化不会太大,如要有重点,如要一事一议,如要有大局观,我们控制成本有如下原则:

  1. 先处理大头的成本或者先控制能产生更大效果的成本点,特别是大的原则;
  2. 不同类别的成本要用不同的策略对待,如生产性成本考虑其投入产出比,监察类成本考虑不做会怎样,带来的成本是多少?
  3. 最有效的降本方式是把某块直接去掉,减少比不上直接清零,评估确实去掉会更好的可以直接干掉;
  4. 要有大局观,不能一个地方成本降低了,另一个地方成本增加了,不能这个月成本低了,但是整体成本却高了,有时我们可以容忍这个月成本高一些,接下来的成本低,总体成本低一些。

在控制成本的过程中,要能识别出成本要素,找出每个要素的关键成本点,将成本定义为顾客付出的代价,根据成本的基本特性对其分类,输出成本诊断报告。在诊断成本时,主要成本可以分为:

  • 生产性成本,是企业为顾客提供他们想要的所愿意购买价值的各项活动而产生的成本,从企业层面来说包括制造成本、促销成本、知识工作和财务工作的成本、销售成本都算。从技术成本来看,服务于客户的线上环境、开发过程中的环境都算在里面;
  • 支持性成本,如传统企业的运输成功,在技术成本中,服务于生产过程的项目管理系统、用于部署和发布的 DevOps 系统等等,他们是流程中不可避免的;
  • 监察成本,不以完成某些任务为目的的活动,只是为了预防或发现问题,如一些监控系统、日志服务等,还有一些如衡量代码质量或产出的系统
  • 纯浪费,没有收获的成本,如一些空转/负载低的机器,一些闲置没有人管的机器

对于以上的成本,我们的思考重点是如果是不花费这个成本,带来的成本会更高吗?

当然,我们控制成本并不是不能有成本,并不是不能增加成本,成本本来就是不存在的,它是为获得成果而存在,至少最开始是这样。就成本控制而言,集中资源去获取成果才是最佳且最有效的成本控制方法,还是要业务有持续的增长

回到技术成本上,对于一个有多条业务线的公司来说,从商业模式的角度来看,我们希望精细化的核算成本,来辅助对业务商业模式的判断。

业务商业模式是否成立,如长期收入无法覆盖成本,是否可以通过压缩或控制成本来实现商业模式成立。具体到业务细节:

  • 我们如何看待免费用户的行为,我们为免费用户投入的成本是多少?
  • 我们对于付费用户投入的成本是多少,ROI 是多少?
  • 对于重点客户/大客户的投入成本是多少,ROI 是多少?

从组织内业务目标达成的角度来看,组织的业务目标中包括成本,从财务层面需要提供更精细化的成本逻辑给到业务方以辅助其做业务判断。

当从财务层面考察成本时,所有的业务为了实现目标,会寻求各种成本降低的措施,此时成本控制中不仅仅包括控制,对于成本的精确度量会变成一个重要的需求,而在技术上有些成本是无法区分的,此时需要我们和业务方一起协调分摊比例。

从一个研发团队的负责人的角度来看,一个成熟的技术管理者,经营思维是一个非常重要的思维,而在经营思维中,成本占据很大比重。

一个公司想要基业长青,除了增长,产生价值,对于成本的敏感和严谨也是非常重要的,对于一个技术团队来说,成本至关重要。

在现在这个行情下,在业绩没有明显增长的情况下,一个团队如果成本太高,可能就会成为动手的主要对象之一,而这里的成本依据上面的 4 种分类,如何诊断,如何持续运营,是一个长期的事情。

成本管理需要安排专人全职负责,是一项重要管理职能。月度成本复盘要持续搞,至少一个月复盘一次,这是最基本的操作。