【IT 基础架构】系统运维实践
基础架构最重要的三点：可靠、简单和高效。基础架构中的两大基石：CMDB 和 Workflow。
更新历史
- 2022.11.26：完成初稿
读后感
看君一本书，胜干三年活。我们通过学习先进经验，再进行实践，就能超额成长，一年更比三年强。对运维人员非常重要的一本书，强烈推荐！
读书笔记
混沌初开
- 基础架构最重要的三点：可靠、简单和高效。
- 基础架构中的两大基石：CMDB 和 Workflow
- 没有 CMDB，信息从哪里来？
- 没有规范的 Workflow，如何确保信息的准确性
- 简单是支撑规模增长、消除扩容瓶颈的基础条件
- 消灭异构形式：不论是通信协议、接口规范还是底层框架
- 消灭重复组件：不要重复造轮子，精力要放在业务场景适用性上
- 消灭紧耦合关系：架构扁平化，消除冗余的层级
- 明确职权界线
- 拆除过度的依赖关系
大家感兴趣的是：
- 整个系统的工作流程是怎样实现的
- 模块之间是如何协同工作的
- 在实现过程中遇到了什么问题，如何解决的
- 这套系统适用于哪些场景
- 什么时候会遇到瓶颈
- 这个模式能否广泛复用
数据中心规划设计
- 网络区
- 安置核心层的网络设备，以及与银行对接的一些专线设备
- 负责人：NE（网络工程师）
- 管理区
- 提供维护管理功能，涵盖所有的基础服务
- 如：部署系统、资产系统、DNS、文件共享、配置管理、监控系统、安全监测系统等
- 负责人：运维团队所有成员
- 数据库区
- 根据实际情况再做细分，例如根据数据库类型来划分，根据业务登记来划分
- 带存储的数据库最好和不带存储的数据库分开安置
- 负责人：运维 DBA
- 应用区
- 安置前端应用服务器，通常位于网络拓扑的 DMZ 区
- 设备数量最多的区域，也是变数最多的区域
- 负责人：PE（产品工程师/应用运维工程师）
- 大数据区
- 对计算能力和存储空间的要求很高，能耗非常惊人，所以不可以和一般机型混放在一起
- 为数据节点服务器选用电力容量更高的机柜
- 名称节点服务器等和其他服务器相比差不多，可以考虑在大数据区内部划出一块地方
- 预发布区
- 模拟线上的真实环境
- 生产系统不允许研发人员直接操作
- 特殊需求区
- 承接各种各样的非主流、临时需求
- 开发区
- 面向研发和测试人员
- 内部也存在逻辑隔离的需求，称为闭环系统
- 沙盘区
- 新技术探索研究或者故障复现
- 比开发区风险更大，要实施隔离
网络空间规划
经典的三层网络架构是由核心、汇聚和接入三部分组成的。为了保障服务的伸缩性、灵活性以及维护工作的一致性，数据中心在建设过程中，采取了模块化的网络部署方式。它将汇聚层、接入层联通服务器等设备统统部署到同一个逻辑单元中，我们称之为 PoD(Point of Delivery)。所有的 PoD 通过核心层设备形成互联。当数据中心需要扩容时，只需水平增加 PoD 即可。
在一个二层网络内，通信基本靠“吼”，设备寻址要借助 ARP 广播来实现。不过广播域规模过大是有害的，会引发巨额开销。二层网络无法隔离广播域，一旦发生广播风暴或 ARP 攻击，整个二层网络内的通信都会受到印象。三层设备可以隔离广播域，但是成本太高，因此使用 VLAN 是一种普遍的解决方案。一个 VLAN 就是一个广播域。默认情况下，不同 VLAN 之间是相互隔离的。
网卡绑定推荐使用 802.3ad layer2+3 的模式，是目前主流互联网比较常用的解决方案。
服务器硬件选型
硬件平台建设初期，应该选择功能强，故障率低、日常维护简单便捷的产品。建议选择两家供应商，减少产品多样化带来的麻烦，也防止被单一产品绑架。
平台建设的中期阶段，业务扩张速度最快，服务器数量明显增多，成本压力很大。为了成本控制和合规，也会引入更多供应商，就会逐步形成异构平台的乱局，要重点做异构融合。
平台建设进入后期，服务器数量非常庞大，单节点故障对于业务的影响已经被弱化甚至消除了，就需要考虑：1）如何精简服务器的硬件配置来降低整体成本，2）如何处理生命周期完结后的老久设备。
选型的总体原则
- 统一规划，明确应用系统在规划期内的规模，对整个应用系统的模块、用户、流程进行分析；确定总体需求，从而定义硬件平台的架构和配置。
- 高可靠性，要求硬件平台长期能够稳定地正常运行。服务器的适用性强，故障率低。在产品生命周期内，确保供应链可靠和备件货源充足。
- 操作便利性，日常操作简单方便，可维护性强，满足大批量集中管理的需求；对于设备运行状态提供有效监控，在出现故障事件时能欧及时预警；分析日志的内容输出详细，可以留存、转发和导出
- 弱化纵向扩容能力，要在硬件产品的整个生命周期内，充分考虑业务需求的延展，硬件配置应当在整个生命周期内都满足业务需要；生命周期结束后，设备升级方案应当采取整机替换，而不是部件升级。
- 符合未来发展走向，要根据 x86 未来应用的发展特点来选择合适的架构，主要宗旨是弱化单节点影响，强调架构简单和分布式的部署方式。
- 产品线平滑过渡，选择主流的产品，确保更新换代时可以平滑过渡，防止出现产品断层，硬件平台选型前后差异化过大，会带来不可估量的风险
- 高性价比，质优价廉
构建 CMDB 与 Workflow
运维的困境就在于，没有提前做好面对质变的准备。团队疲于应付基于故障处理、基于业务需求的工作，完全没有时间，甚至没有就产品价值和用户价值去思考问题的意识。
忙，成为一切拖延症的最佳理由。团队在事务优先排序上选错了度量工具，不用价值来衡量，却非要去和时间赛跑，陷入明日复明日的怪圈。
CMDB(Configuration Management Database，配置管理数据库)用于存储与管理企业 IT 架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相连，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程来保证数据的准确性。
衡量一个运维团队的能力如何，有一个非常简单粗暴的判断依据，就是检查他们的 CMDB 到底能做到什么程度，CMDB 是一切运维的基石。
对于监控告警平台的要求，不是说故障出现时，能够及时发出警报这么简单，要把所有相关的信息都发送出来才行。什么信息都没有，光喊狼来了，那是不行的。警报发出来，就意味着战斗，就必须弄清楚敌人的全部情况才行。
最糟糕的运维就是在没有打好基础的时候，反倒是先把上层建筑都统统搞起来了，唯独丢掉了最重要的 CMDB，用 Excel 表格来自欺欺人，后期信息缺失全靠人肉支撑。先盖楼、后打地基正是某些运维团队的现状。这样做的理由就是因为打地基的成本高，进度慢，所以就先拿一个东西来凑合，剩下的以后再说。
CMDB -> Deployment -> Management > Monitor Platform -> Business Review -> Cost keeping
在构建 CMDB 的过程中，实际上是一个业务逻辑梳理的全过程。因此，CMDB 的整个架构应当由业务团队去构建，而不是甩给开发团队。不懂业务就没有发言权。缺少对业务的深度理解，就无法全面准确地定义配置项以及建立它们之间的关系模型。
Workflow 是规范的实例化体现，它是一套嵌入流程的自动化工作系统，主要的作用是确保用户执行过程的标准化、规范化。
硬件故障告警与维修
硬件故障有量大特点：
- 部件损坏的范围比较集中。最容易出问题的是机械硬盘和阵列卡，其次是内存、电源和 SSD
- 故障发生的时间点相对集中。因为采购的时候是按照批次的。
硬件告警最好能够与 CMDB 实现联动，这样告警时能携带更多的相关信息。
主机系统信息安全
sudo over LDAP，可以避免使用配置管理工具同步
修行之路
工程师与管理员的的差别：
- 表和里的差别 —— 技术深度
- 点和面的差别 —— 驾驭能力
系统工程师的三颗心：
- 对生产系统要怀敬畏心
- 对业务需求要存谨慎心：不得罪人的 SE 不是好 SE
- 对功名利禄要抱平常心
从现在开始就要改变自己：
- 放大格局。从整体、宏观的角度来思考问题，把解决一件事提炼升华成解决一类事。
- 无谓加班是无能的表现。
- 自找苦吃。如果没有压力，就说明工作还不到位，还没有达到全力以赴的满负载状态。
- 为自己打工。做事有四种态度：
- 做牛马 —— 把工作当负担，糊弄着做
- 做任务 —— 把工作当差事，尽职做
- 做产品 —— 把工作当市场价值，用心去做
- 做品牌 —— 把工作当成文化传承，注魂去做
- 受尊重的都是有实力的人
- 我们不可能让所有人都满意
开启你的管理模式
- 为什么你需要管理
- 原本有一个远大的抱负，却终日被琐事所累，那是因为你不懂得目标管理
- 每天累得像条狗，那是因为你不懂得时间管理
- 工作了很多年却没什么积蓄，那是因为你不懂得财富管理
- 一直在职场上打转，不断跳槽，工资却没涨多少，那是因为你不懂得执业管理
- 升职无望、被迫失业，感觉天都塌了，那是因为你不懂得危机管理
- 你必须要懂管理
- 通过管理，掌控自己的命运，朝向着你自己的人生道路去前行
- 不懂管理你将永远被动
- 你关注的是细节，他关注的是格局
- 你研究的是技术，他研究的是市场
- 你在看架构融合，他在想风险融资
- 你加班加点为刚解决一个 bug 而松一口气。与此同时他在饭桌前与客户觥筹交错，畅谈产品构想和行业价值
- 你每天下班到家已是深夜，连晚饭还没有吃。他不断出入各种高端社交场合，获取了大量的人脉资源
- 你发现自己活得越来越累，好像身体已被掏空。他时间越来越充裕，有很多进修、学习、思考的机会
- 你每天上班是痛苦的，想着昨天还有两个工单没有干完。他每天上班是开心的，憧憬着未来的幸福