20210221阅读笔记

对“懂IT的管理者”而言，IT只是众多技能中的一项，无甚稀奇，他考虑和决策的标准是生意，是通盘的管理。在懂得IT价值的同时，一定也要能看到整条价值链，看到其它团队的价值所在，不要做僭越自己身份的事情。把这些追新的精力用来提升自己取舍的能力，与人交流协作的能力，打磨工作方式的能力，价值定位的能力，对提升个人价值来说往往反而能起到事半功倍的效果。
不过，千万不要被“越界”和“变身”给吓倒了，以我的经验，最大的困难来自于你的大脑，只要不时时刻刻绷着“我是（跟其他人不同的）IT人”的那根弦，剩下的都好办。

管理类

从“懂管理的IT人”，到“懂IT的管理者”
https://mp.weixin.qq.com/s/sj9z5nwKytD8eOquOiwORA

对“懂管理的IT人”来说，管理只是拱卫IT的能力之一，补齐短板所需，他考虑的坐标系仍然是IT，许多从IT出身的领导都是这样。
但是对“懂IT的管理者”而言，IT只是众多技能中的一项，无甚稀奇，他考虑和决策的标准是生意，是通盘的管理。

1. 取舍技术方案

• “懂管理的IT人”，无论放弃哪个方面，都让我感到异常纠结，无比难受，因为它。但如果定位为“懂IT的管理者”，我非常清楚必须放弃某些方面，而且不能犹豫，因为犹豫反而会错失时机，而时机对生意来说往往是无比重要的。
• 所以，“懂IT的管理者”平时可以耐心跟大家讨论技术方案的优劣，一旦遇到资源有效、目标明确的场合，必须毫不犹豫地放弃自己对技术的执念，迅速定下取舍。近年来，我已经不止一次地告诉程序员：对，这样做确实很丑，但别犹豫，赶紧动手吧。

2. 与人打交道
   “懂IT的管理者”，那么面对面交流、讨论就变得相当重要——几乎所有的管理者课程都强调沟通的重要性。沟通交流的目的，绝不是需要草草敷衍，然后可以让自己醉心编码，而是保证自己的信息灵通，协作顺畅。这一切都搞定之后才轮到处理具体事务，IT只是诸多“具体事务”中的一项而已。

3. 工作方式
   比较可取的办法是先着眼于目的，摸索出各方的最大公约数。然后，在自己能决定的范围里践行自己的工作方式，在这个范围之外，则以目的优先，绝对不要过多计较工作方式——要知道，在你没有绝对权力，也没有绝对话语权优势的时候，单纯强调工作方式多半会碰得头破血流，尤其是在业务部门面前。
   另外，也别执着于凡事都要以系统、流程、规范来做，它们未必是人人认可的工作方式，甚至可能让人觉得繁琐和反感。

4. 价值眼光

• “懂管理的IT人”，往往在能力上并没有明显的短板，但他的工作节奏和思考重心仍然是IT，想着如何把IT做好。这本来没有错，可惜的是，不是每家公司都需要那么好的IT，至少不那么迫切需要——别信老板们的鬼话，看看他们的投入就知道了。
  我以前的领导曾跟我说过一句话，让我印象深刻：你们把系统做好，公司当然喜欢，但更重要的是，你们应当从价值链的角度出发，找到自己的定位。
• 如果你是“懂IT的管理者”，在懂得IT价值的同时，一定也要能看到整条价值链，看到其它团队的价值所在，不要做僭越自己身份的事情。同时，也需要想办法影响大家的印象，强调自身的价值。哪怕你很诚实，希望用一套客观的数据体系去证明自己的价值，起码也应当先设计出这套数据体系，获得大家的共同认可，并在工作中持续发出信号。
  所谓“价值链”，其实也没有那么玄乎，一般来说，主要包含两大因素：人事、财务。无论在哪家公司，这两大因素基本都是不变的，剩下的只是你如何从这两个角度展开，看待和证明自己的价值。

5. 职业价值

• “懂IT的管理人”的定位可以让人摆脱技术的焦虑感。什么是技术的焦虑感？就是面对层出不穷的新技术，永远在学习，永远在追赶，永远担心被拉下的忧虑。
• 为什么“懂IT的管理人”可以摆脱这种焦虑？因为相比技术的更新速度，生意和组织的更新速度要慢得多。实际上，如果我们把目光从头部的那几家“技术弄潮儿”移开，就会发现很难有公司一直引领技术潮流，甚至大部分公司（恰恰是它们解决了大部分IT就业）根本不需要那么高精尖的技术，它们更需要的是用合适的技术去解决自己生意中的具体问题。
  一旦具备了这种“提供合适技术”的能力就会发现，错过几波技术新浪潮，或许并不那么让人担心，一味追新反倒很可能浪费。另一方面，把这些追新的精力用来提升自己取舍的能力，与人交流协作的能力，打磨工作方式的能力，价值定位的能力，对提升个人价值来说往往反而能起到事半功倍的效果。
  “懂管理的IT人”相对容易，只要懂IT的人补齐基本的管理知识，没有明显短板就可以，所以竞争也会相对激烈。“懂IT的管理者”相对更难，因为很难想象其它管理者能主动学会IT，所以它只能来源于搞IT的人主动变身，主动越界。

不过，千万不要被“越界”和“变身”给吓倒了，以我的经验，最大的困难来自于你的大脑，只要不时时刻刻绷着“我是（跟其他人不同的）IT人”的那根弦，剩下的都好办。

---

码农和技术管理者的区别，到底在哪里？
https://mp.weixin.qq.com/s/U0o84rR3vtccQji2oIVK5w

1. 两个问题
   第一个问题，技术管理者的核心能力是什么。技术管理者的核心能力就是技术判断力。技术判断力简单说来，就是某个技术项目“要不要做”，要做的话“能不能实现”，是否适合现在做，还要考虑技术风险、项目管理复杂度、成本等，已经远远超出了写代码的范畴。
   第二个问题，技术工程师和技术管理者的技术能力有什么差别呢？简单来说，技术工程师的技术能力就是写代码，做具体的技术实现。技术管理者的技术能力是技术判断力，通过在技术领域和非技术领域的长期积累培养起来的技术决策能力。

2. 技术判断力主要体现在三个方面：
   第一，对结果的判断。
   第二，对技术方案的判断。技术管理者对技术方案的判断也比技术工程师思考得更深、更全面，技术工程师或许只考虑好不好实现，而技术管理者要确保在方向上不出现大的偏差。
   第三，对风险的判断。技术管理者平时做的技术评审、项目回顾、技术方案规划等工作就是在做技术判断，技术能力并没有变差，因为作为技术管理者，技术判断力在日常工作中得到了持续的锻炼和提升。

3. 如何提升技术判断力？
   第一，团队日常技术和产品工作汇报。团队在汇报技术和产品进展时，是获取信息反馈、验证技术判断的大好时机，看看自己之前的技术决策产生了哪些影响，有无需要调整的地方，也可以学到下属们的思考和经验，及时更新自己的技术和产品认知。
   第二，参与技术方案评审。小到每次Code Review，大到系统整体方案评审，都要尽量参与，尤其是大型系统整体架构评审，这是系统化提升技术判断力最好的机会，架构师的讲解，包括架构设计的逻辑、每种技术的特性等，结合自己的理解和经验给团队提供反馈，架构判断能力也可以得到提升。
   第三，主持系统顶层设计和规划。
   第四，持续学习新技术。
   关注的是这项技术解决什么问题、实现的原理和机制，而不是如何熟练使用这个新技术写“Hello World”，当然写一些demo对于加深理解是有必要的。

---

从“开发人员≠厨师”说起
https://mp.weixin.qq.com/s?__biz=MzA3MDMwOTcwMg==&mid=2650004794&idx=1&sn=6262e972c1175b5bc07c0e8bb4f12230&chksm=8739bf13b04e36053aef64531ea8803613b1d375d86a7af4c8ffa39a117397566e347d7e243d&scene=21#wechat_redirect

讲一样，也一样，都是靠手艺吃饭。我的经验是，吃手艺饭，你当个体户没问题。但是，你见过一群手艺人配合起来天衣无缝的不？我是没见过。关键还是那句话，这个世界上的本事千千万万，莫以为就你那点手艺最要紧，其它本事都看不上。我们靠手艺出身的人，只要过了这一关，其它就都好办。

技术类

https://mp.weixin.qq.com/s/JYRz5zu3AhTEovOcDR4FRQ

搭指标体系可是数据分析师的必备技能，也是数据分析岗位进阶的核心竞争力

---

进击的 Flink：网易云音乐实时数仓建设实践
https://mp.weixin.qq.com/s/ssluyzPlNv8kBv_Teq24dw

• 在一个 Flink 任务的开发中，涉及的数据源主要有三类：
  • 流式数据：来自 Kafka 或者 Nydus，可以作为源端和目标端；
  • 维表 JOIN 数据：来自 HBase 、Redis、JDBC 等，这个取决于我们自己实现了哪些；
  • 落地数据源：一般为 MySQL、HBase、Kudu、JDBC 等，在流处理模式下通常作为目标端。

我们认为批流一体主要分以下三个方面：

1. 结果的批流一体
   使用数据的人不需要关心数据是批处理还是流处理，在提交查询的那一刻，拿到的结果就应该是截止到目前这一刻最新的统计结果，对于最上层用户来说没有批和流的概念。

2. 存储的批流一体

   • 上面的 ABTest 例子中我们已经看到 DWD、DWS 层数据的存储上还有很多不足，业界也有一些相应解决方案等待去尝试，我们希望的批流一体存储需要以下几个特性：
   • 同时提供增量订阅读取以及批量读取的能力，如 Apache Pulsar，我们可以批量读取它里面的归档数据，也可以通过 Flink 订阅它的流式数据，解决 DWD 层两套存储的问题。
   • 高性能的实时 / 批量 append 和 update 能力，读写互不影响，提供类似于 MVCC 的机制，类似于 Kudu 这种，但是性能需要更加强悍来解决 DWS 层存储的问题。
   • 和 OLAP 引擎的对接能力，比如 Impala、Presto 等，并且如果想要提升查询效率可能还要考虑到列式存储，具备较强的 scan 或者 filter 能力，来满足上层用户对业务结果数据查询效率的诉求

3. 计算引擎的批流一体
   做到一套代码解决批流统一场景，降低开发运维成本，这个也是 Flink 正在努力的方向，未来我们也会在上面做一些尝试。