运维建设之架构思考

导读

本文将断续、松散的记录,楼主从「传统运维」转型到「基础设施架构」过程中的一些思考。

云原生

2021.05.16 云原生的定义

云原生是一套开放的基础设施建设标准。基本上,向下抽象IaaS、中间约定PaaS建设规范、对上呈现应用接口。

K8S是云原生标准的一套开源实现方案,其理论基础脱胎于谷歌borg。在IaaS资源抽象、PaaS托管规范方面做的不错,向上的应用接口还在进一步优化中。

K8S不等于云原生。符合标准的公有云、私有云、混合云方案,均可认为是云原生。

2021.04.01 云原生时代的Devops

云原生时代,Devops的职能从运维团队、转移到了基础设施(云原生)团队。这加剧了运维岗位的运营化。

职能转移,主要动力在于:K8S体系吸收、囊括了Devops建设思想,使得Devops单独存在的必要性降低。

技术

2021.09.30 康威定律

康威定律(Conway’s Law)是马尔文·康威1967提出的:「设计系统的架构受制于产生这些设计的组织的沟通结构」。通俗的来讲:有什么样的组织结构、就有什么样的产品架构。康威定律可以细分为四条规律:

  • 第一定律,组织沟通方式会通过系统设计表达出来。Communication dictates design。
  • 第二定律,时间再多一件事情也不可能做的完美,但总有时间做完一件事情。There is never enough time to do something right, but there is always enough time to do it over。
  • 第三定律,线型系统和线型组织架构间有潜在的异质同态特性。There is a homomorphism from the linear graph of a system to the linear graph of its design organization。
  • 第四定律,大的系统组织总是比小系统更倾向于分解。The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。

原文,来自恶心的360文档库这里

2021.08.24 架构师的价值

对于绝大多数的架构师来说,他的价值不在于创新了什么,而在于为公司选择一条稳妥的、合适的路。

不求原创,但求合适。

2021.08.09 关于架构技术选型(摘录)

架构技术选型时,需要做好两个事情:

  • 做好长短期利益的权衡
    • 问题:架构选型时,一般会面对 1、短期的痛点,2、中期的瓶颈,3、长期的先进性。技术经常面临的问题是,长期容易被低估、短期又会被高估
    • 原因:究其原因,人类的天性就是容易看到眼前的问题和痛点,在思考问题时也会从眼前的问题着眼入手出发。这本身是无可厚非的,也是符合客观规律的。毕竟,「先活下来」永远是思考的第一要素。
    • 解法:但是对于资深的架构师来说,技术选型中短期的利益往往是会和中长期的收益存在着或多或少的矛盾和取舍。这就要求,有时候要放弃短期的最优解,采用次优解,来平衡短期和长期的利益
  • 客观思考、避免个人偏执
    • 问题:每一位架构师其实都有一些自己的偏好,有一些自己的执念。
    • 解法:从实际问题出发,避免个人的经历、偏好、执念对技术选型的影响。在做技术选型时,能时刻警醒自己,跳出来,从一个相对客观的角度,从问题域出发去评估整体选型,而不是从具体的手段、方法来看待问题,尽量避免手里有锤子,一切问题都是砸钉子的事情发生。
    • 举例:当然,这也是一个知易行难的事情。我个人的一个具体实践是,在做技术选型和设计时,即使未来是要自己去落地,也不会把自己代入未来的执行层面或者实施层面去思考细节。当然,如果设计和落地本身是分离的,就没这个烦恼了。但是,大多数时候架构师是没机会真正置身事外的做一个「顾问」的。

2021.04.01 美团的技术演进思路

技术建设,要比业务需求快一步、比业界先进慢一步。要在技术的体系性、思考深度上,做到业界最牛。

这是美团的跟跑策略,在技术方向的体现。略有参考价值。

元数据

2020.09.25 元数据的特点

好的元数据,具备的特征:强依赖、可收敛、可复用、可校验

  • 强依赖,至少被1个关键业务路径依赖;
  • 可收敛,生成成本可以逐渐降低,数据质量可以逐渐提升;
  • 可复用,能被2+个场景使用、实现价值扩展;
  • 可校验,在现有元数据体系中,能交叉互验数据的正确性,降低修复更新成本

是否有利于元数据的收敛,是判断一个运营方案好坏的重要指标。如,

  • CD审批,上线审批权限点是一个差方案、因为审批权限生成过程收敛成本高
  • 服务负责人审批是一个好方案、因为服务负责人是一个可以被精心维护的元数据

说的再激烈一点,元数据不收敛、罪一定在平台(运营方案)~



Prev     Next