04
归纳思维
Aliware
很多时候，我们习惯了碰到问题，都希望能快速的解决，而快速解决的方法很多只能是做表面工作，从表面解决，从表面上下功夫，头痛医头脚痛医脚，不追究发病的病根，看似很快，实则隐患不少，待问题再出现的时候代价会更大，其实最快的解决问题是从根本上解决问题，虽然这样前期不能最快解决问题，投入的精力也会很多，但是投入的成本低，在没有形成顽疾的时候，提前介入，一劳永逸。
“物有本末，事有始终，知所先后，则近道矣。”，当我们了解了一件事情的来龙去脉，掌握了事情的本末结构 就基本探究到了事情的本来面貌，归纳思维让我们可以从一个个具体的事例中，推导出它们的一般规律和共通结论的思维。帮助我们寻找问题的根因，从而对症下药解决问题。归纳思维的方法有很多在此不做讨论，生活中运用到归纳思维的例子有很多。天空乌云密布，燕子低飞，蚂蚁搬家等现象时，我们会得推断说天要下雨了。还有很多比如立冬晴一冬凌，立冬阴一冬温等等。归纳思维应用于工作中，可以帮助我们通过个别问题归纳推演出一类问题的共性和规律，采取合理的方案解决问题，举几个身边的例子：
01
开发人员运维投入成本的问题
部门成立初期由于业务上的变化较大，为了支撑业务，底层数据模型的做了一次升级，新增了部分数据模型，兄弟团队或者业务运营同学经常会丢一个单子过来让开发同学人工帮忙查单据状态、物流进度、单据关系等，这个造成了值班的开发同学编码时间经常被打断，效率下降，所以我们归纳推演了下分析问题的本质是【运维工具上的缺失】，基于此问题根因孵化了<火尖枪>和<乾坤圈>，降低了开发同学的运维投入的问题。
02
火尖枪
根据任意单号快速查询全链路数据的工具，实现从交易场到物流场全链路数据一键查询。
03
乾坤圈
通过单据的生命周期和单据之间的关系管理沉淀了"AAR"模型，实现任意单号/关键字全链路日志搜索并按照实际发生时间链式展示。
04
业务快速分析的问题
为了更好的支撑业务接得快、改的少、让系统更加高可用，FY22 财年针对目前系统架构做了一次升级，本次升级和以往不同的是：技术和业务支撑同步进行且有人员资源上的问题，抽调了一部分负责数据和异常较多的同学来参加架构升级，所以一个问题就出现了：对线上业务的了解和差异分析。这个了解不单独是知道业务是什么，要知道线上的业务所有细节，包括这个业务下的一个开关在做什么。这个对于当时参加的同学和架构来言都是一个很大的挑战。通过归纳总结，我们把一些好的案例规整以后产生出了一个业务梳理大纲，按照这个大纲去梳理业务，同时持续完善这个大纲。让所有同学都可以先有一个大的视角来看，忽略一些细枝末节。梳理的业务大纲如下：
1.通用资料库
2.作业模版分析
3.业务身份分析
4.实操节点(仓、运、配等)接入方式分析
5.调度协同分析
6.售中逆向分析
7.售后逆向分析
8.财务/库存分析
9.核心业务流程分析
10.数据库关键字段分析
11.广播消息汇总
12.业务分析汇总
13.线上示例单据&消息整理
14.关键报文
15.单据属性对比
16.领域消息对比
17.架构升级新增测试点
18.特别测试场景提醒
19.自测案例
持续的归纳总结，不仅是让工作做的更好更轻松，更多的是对自己不断产生出滚雪球的收益，所以从这个需求/这个问题排查开始，多问几个为什么。
05
结构化思维
Aliware
先来看下下面这些数字，然后在 10 秒内说出所有数字和字母：
2, 4, f, 8, n, 4, 2, 3, 7, d, b, a, h, e, k, m, i, 3, g, j, 9, 6, 5, 1, 1, 0, c, l
面对这样一堆没有任何规律的数字，如果要记下来是不是有点难？如果我们把这些数字的内容调整下，变成下面这样：
0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, g, h, i, j, k, l, m, n
是不是清晰了很多？
其实这涉及到了结构化思维：当人接收到大量杂乱信息时，处理复杂信息的能力有限，但是更偏爱有规律的东西。我们每天工作生活中都会接收到大量信息，如何把这些信息吸收并结构化为我所用就需要构建自己的知识树。比如上面的业务梳理大纲的例子，其实我们就构建了一个自己的知识树，通过它我们可以检索我们需要的信息，好的知识树可以借鉴，但是每个人都有自己的一个思维方式，如果没有内化成自己的或者不是自己构建的知识树无法熟练的使用。
结构化思维指从整体思考到局部，是一种层级分明的思考模式。简单来说就是借用一些思维框架来辅助思考，将碎片化的信息进行系统化的思考和处理，从而扩大思维的层次，更全面地思考。没有结构化的思维是零散混乱无条理的想法集合，而结构化思维是一个有条理有层次，脉络清晰的思考路径，让这些点连成了线，举一个常用的问题解决方法思维框架：
按照这个思维框架，很多问题的解决都可以用的上，比如上面举过的一个数据中心的例子，应用这个思维框架后，基本思维路径如下：
06
总结
Aliware
一线技术人每天面临的都是写需求、改缺陷、查工单，加班，长此以往。有时候不妨跳出来以一个旁观者的身份看一看自己，做一个需求前多问几个为什么？写一段代码前先理一下逻辑思路，需求发布以后想一下怎么运维(最好的是让没做过这个需求的人也知道怎么处理工单，打破知识壁垒和人员壁垒)，在这个域沉淀的东西如何复用到另外一个域。我们面临的业务是变化的但是做事的方法是有共性的，如何沉淀这些共性的做事方法才是做业务需求带来的最大成长。
低头走路，抬头看天，长路漫漫，不忘初心 -- 自勉
