技术转管理
技术管理者的核心能力，就是技术判断力。技术判断力简单说来，就是某个技术项目“要不要做”，要做的话“能不能实现”，是否适合现在做，还要考虑技术风险、项目管理复杂度、成本等等，已经远远超出了写代码的范畴。
技术判断力，都判断哪些方面的事情？
我放下了手中的咖啡杯说到，技术判断力主要体现在三个方面：
第一，对结果的判断。即这个事情做还是不做，用什么样的指标来衡量它的好与坏。
第二，对技术方案的判断。即对技术可行性、可维护性、成本收益等方面进行判断，通常在技术方案评审环节给团队进行指导。比如这个方案是否具备技术可扩展性，能不能为公司建立起技术壁垒，技术框架里有没有详细日志记录，出现线上故障是否有预警，并且提供详细的错误日志进行分析，选择这项技术的机会成本如何？所谓机会成本，即选择这项技术就会放弃别一项技术，有没有可能另一项技术的收益更大？
第三，对风险的判断。包括技术风险、项目执行风险、团队风险等方面。技术管理者利用自己的经验、思考分析、团队讨论等手段，识别出主要的风险，并采取措施进行规避。
技术评审、项目回顾、技术方案规划等工作，就是在做技术判断。
如何提升自已的技术判断力？
新技术管理者的技术判断力，主要来源于之前写代码和做项目的经验积累，这时候要做好知识迁移，将技术工程师的经验认知，转换成技术管理者技术判断的认知。
主要有四个方面：
第一，团队日常技术和产品工作汇报。团队在汇报技术和产品进展时，是获取信息反馈，验证技术判断的大好时机，看看自己之前的技术决策产生哪些影响，有无需要调整的地方，也可以学到下属们的思考和经验，及时更新自己的技术和产品认知。
第二，参与技术方案评审。小到每次code review，大到系统整体方案评审，都要尽量参与。尤其是大型系统整体架构评审，这是系统化提升技术判断力最好的机会，架构师的讲解，包括架构设计的逻辑，每种技术的特性等等，结合自己的理解和经验给团队反馈，架构判断能力也得到提升。
第三，主持系统顶层设计和规划。技术管理者可直接担任或主持系统顶层设计规划，业务架构规划、系统各层的划分、子系统之间的数据交互协议、技术框架选型、系统容量规划等等，从技术整体架构进行把控，再由团队进一步展开做更细的规划。
第四，持续学习新技术。从事技术管理工作，并不是说完全丢弃技术，只是放弃了大部份的代码工作，但是新技术的学习是不能停止的，比如人工智能的技术框架、机器学习的几种模式以及擅长解决哪些问题。再比如区块链几种共识算法的特点、实现原理、加密算法、记账方式差异等等。关注的是这项技术解决什么问题、实现的原理和机制，而不是如何熟练使用这个新技术写Hello World，当然写一些demo加深理解是有必要的。
互联网技术经理工作最佳实践
架构师
《揭秘阿里中台的12个架构思维和原则》
架构师需要能够识别定义并确认需求，能够进行系统分解形成整体架构，能够正确地技术选型，能够制定技术规格说明并有效推动实施落地。架构师的角色有：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。
从业界来看对于架构师的理解可以大概区分为：
-
企业架构师：专注于企业总体 IT 架构的设计。
-
IT 架构师-软件产品架构师：专注于软件产品的研发。
-
IT 架构师-应用架构师：专注于结合企业需求，定制化 IT 解决方案；大部分需要交付的工作包括总体架构、应用架构、数据架构，甚至部署架构。
-
IT 架构师-技术架构师：专注于基础设施，某种软硬件体系，甚至云平台，提交：产品建议、产品选型、部署架构、网络方案，甚至数据中心建设方案等。
解决方案架构师
★ 工作方式理解
-
了解和挖掘客户痛点，项目定义，现有环境管理；
-
梳理明确高阶需求和非功能性需求；
-
客户有什么资产，星环（阿里电商操作系统）／阿里云等有什么解决方案；
-
沟通，方案建议，多次迭代，交付总体架构；
-
架构决策。
★ 职责
1.从客户视图来看：
-
坚定客户高层信心：利用架构和解决方案能力，帮忙客户选择星环／阿里云平台的信心。
-
解决客户中层问题：利用星环／阿里云平台服务+结合应用架构设计/解决方案能力，帮忙客户解决业务问题，获得业务价值。
-
引领客户 IT 员工和阿里生态同学：技术引领、方法引领、产品引领。
2.从项目视图看：
-
对接管理部门：汇报技术方案，进度；技术沟通。
-
对接客户 PM，项目 PM：协助项目计划，人员管理等。负责所有技术交付物的指导。
-
对接业务部门和需求人员：了解和挖掘痛点，帮忙梳理高级业务需求，指导需求工艺。
-
对接开发：产品支持、技术指导、架构指导。
-
对接测试：配合测试计划和工艺制定。配合性能测试或者非功能性测试。
-
对接运维：产品支持，运维支持。
-
对接配置&环境：产品支持。
-
其他：阿里技术资源聚合。
3.从阿里内部看：
-
销售方案支持；
-
市场宣贯；
-
客户需求Facade；
-
解决方案沉淀。
架构思维
自顶向下构建架构
自底向上推导应用架构
领域驱动设计架构
大部分传统架构都是基于领域模型分析架构，典型的领域实现模型设计可以参考DDD（领域驱动设计），详细可以参考《实现领域驱动设计》这本书，另外《UML和模式应用》在领域建模实操方面比较好，前者偏理论了解，后者便于落地实践。
基于数据驱动设计架构
常见通用／标准化的架构框架
TOGAF
TOGAF（The Open Group Architecture Framework）: 强调商业目标作为架构的驱动力，并提供了一个最佳实践的储藏库，其中包括 TOGAF 架构开发方法（ADM）、TOGAF 架构内容框架、TOGAF 参考模型、架构开发方法（ADM）指引和技术、企业连续统一体和 TOGAF 能力框架。
Zachman
Zachman 框架模型分两个维度：横向维度采用6W（what、how、where、who、when、why）进行组织，纵向维度反映了 IT 架构层次，从上到下（Top-Down），分别为范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。横向结合6W，Zachman 框架分别由数据、功能、网络、人员、时间、动机分别对应回答What、How、Where、Who、When 与 Why 这六个问题。
ITSA
世界最早的企业架构框架(IT战略与架构):Everything you need, and nothing you don’t.
DODAF
美国国防部架构框架，是一个控制“EA开发、维护和决策生成”的组织机制，是统一组织“团队资源、描述和控制EA活动”的总体结构。涵盖 DoD 的所有业务领域，定义了表示、描述、集成 DoD 范围内众多架构的标准方法，确保架构描述可比较、评估，提供了对 FoS (系统族)和 SoS (体系)进行理解、比较、集成和互操作共同的架构基础，提供开发和表达架构描述的规则和指南,但不指导如何实现。DODAF 核心是8个视点和52个模型。
其中TOGAF，Zachman应用很广泛，TOGAF 还有专门的架构认证。
当我们掌握了这些框架，我们是不是需要一些架构原则来指导更具体的设计
架构原则
设计原则就是架构设计的指导思想，它指导我们如何将数据和函数组织成类，如何将类链接起来成为组件和程序。反向来说，架构的主要工作就是将软件拆解为组件，设计原则指导我们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等。
设计原则有很多，我们进行架构设计的主导原则是 OCP（开闭原则），在类和代码的层级上有：SRP（单一职责原则）、LSP（里氏替换原则）、ISP（接口隔离原则）、DIP（依赖反转原则）；在组件的层级上有：REP（复用、发布等同原则）、CCP（共同闭包原则）、CRP（共同复用原则），处理组件依赖问题的三原则：无依赖环原则、稳定依赖原则、稳定抽象原则。
1.OCP（开闭原则）：设计良好的软件应该易于扩展，同时抗拒修改。这是我们进行架构设计的主导原则，其他的原则都为这条原则服务。
2.SRP（单一职责原则）：任何一个软件模块，都应该有且只有一个被修改的原因，“被修改的原因“指系统的用户或所有者，翻译一下就是，任何模块只对一个用户的价值负责，该原则指导我们如何拆分组件。
3.LSP（里氏替换原则）：当用同一接口的不同实现互相替换时，系统的行为应该保持不变。该原则指导的是接口与其实现方式。
4.ISP（接口隔离原则）：不依赖任何不需要的方法、类或组件。该原则指导我们的接口设计。当我们依赖一个接口但只用到了其中的部分方法时，其实我们已经依赖了不需要的方法或类，当这些方法或类有变更时，会引起我们类的重新编译，或者引起我们组件的重新部署，这些都是不必要的。所以我们最好定义个小接口，把用到的方法拆出来。
5.DIP（依赖反转原则）：指一种特定的解耦（传统的依赖关系创建在高层次上，而具体的策略设置则应用在低层次的模块上）形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖关系被颠倒（反转），从而使得低层次模块依赖于高层次模块的需求抽象。
跨越组建边界的依赖方向永远与控制流的方向相反。该原则指导我们设计组件间依赖的方向。
依赖反转原则是个可操作性非常强的原则，当你要修改组件间的依赖方向时，将需要进行组件间通信的类抽象为接口，接口放在边界的哪边，依赖就指向哪边。
6.REP（复用、发布等同原则）：软件复用的最小粒度应等同于其发布的最小粒度。直白地说，就是要复用一段代码就把它抽成组件，该原则指导我们组件拆分的粒度。
7.CCP（共同闭包原则）：为了相同目的而同时修改的类，应该放在同一个组件中。CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。
对大部分应用程序而言，可维护性的重要性远远大于可复用性，由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。
8.CRP（共同复用原则）：不要强迫一个组件依赖它不需要的东西。CRP 原则是 ISP原则在组件层面的描述。该原则指导我们组件拆分的粒度。
相信你一定有这种经历，集成了组件 A，但组件 A 依赖了组件 B、C。即使组件 B、C 你完全用不到，也不得不集成进来。这是因为你只用到了组件 A 的部分能力，组件 A 中额外的能力带来了额外的依赖。如果遵循共同复用原则，你需要把 A 拆分，只保留你要用的部分。
REP、CCP、CRP 三个原则之间存在彼此竞争的关系，REP 和 CCP 是黏合性原则，它们会让组件变得更大，而 CRP 原则是排除性原则，它会让组件变小。遵守REP、CCP 而忽略 CRP，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；遵守 REP、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改 n 个组件，带来的成本也是巨大的。
除了上述设计原则，还有一些重要的指导原则如下：
1.N+1设计：系统中的每个组件都应做到没有单点故障；
2.回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
3.禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
4.监控设计：在设计阶段就要考虑监控的手段，便于有效的排查问题，比如引入traceId、业务身份 Id 便于排查监控问题；
5.多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
6.采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的 bug，出了问题没有很好的商业支持可能会是一个灾难；
7.资源隔离设计：应避免单一业务占用全部资源；
8.架构水平扩展设计：系统只有做到能水平扩展，才能有效避免瓶颈问题；
9.非核心则购买的原则：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
10.使用商用硬件：商用硬件能有效降低硬件故障的机率；
11.快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
12.无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
架构师知道了职责，具备很好的架构思维，掌握了通用的架构框架和方法论，使用架构原则进行架构设计，不同的业务和系统要求不一样，那么有没有针对不同场景的系统架构设计？下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍，以便于我们在实际运用中进行参考使用。
分布式架构演进（略）
随着服务的不停升级，总有些意想不到的事发生，比如 cache 写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？
针对这些问题，下述的单元化架构，微服务架构以及 Serveless 架构可以一定程度解决，另外针对业务系统，需要做到业务与业务隔离、管理域和运行域分开、业务与平台隔离方可解决上述问题。
单元化架构（略）
SOA架构
SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：
（1）可从企业外部访问
（2）随时可用
（3）粗粒度的服务接口分级
（4）松散耦合
（5）可重用的服务
（6）服务接口设计管理
（7）标准化的服务接口
（8）支持各种消息模式
（9）精确定义的服务契约
为了实现 SOA，企业需要一个服务架构，下图显示了一个例子：
在上图中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
★ SOA和微服务的区别：
-
SOA喜欢重用，微服务喜欢重写；
-
SOA喜欢水平服务，微服务喜欢垂直服务；
-
SOA喜欢自上而下，微服务喜欢自下而上。
Serverless 架构
1、思想：无服务器是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。
2、优势：消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。
3、内容：目前业界较为公认的无服务器架构主要包括两个方面，即提供计算资源的函数服务平台 FaaS，以及提供托管云服务的后端服务 BaaS。
三个less感觉很好：
-
Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。
-
Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。
-
Serverless 对应的则是服务运维，有了 Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容。
架构师在完成上述架构设计后，最终是需要协同利益相关方一起按项目化运作落地拿结果，那么应该如何保证利益相关方在项目落地的满意度，如何保证按照架构很好的拿到项目成功的结果呢？架构管理能力是架构师非常重要的能力。
架构管理
架构共赢模型