读《流量从10万到10亿》有感

多年的运维感悟，什么阶段干什么事。这也是我在内部的运维规范里明确标明，“不提前优化”

我来谈谈几个阶段，

初创阶段，更多关注业务最小模型能否跑通
- 快速实现
- 熟悉什么技术栈，就用什么
- allinone
- 引入ORM、DAO屏蔽sql复杂性
- 早期不自研
- 规模扩大的时候，要浅浅的封装一层，防止日后技术栈更新，控制数量。我称之为“有中台作用，但无中台负重”
- 只有在开源社区无法满足时，再造轮子
需要容量评估的场景
- 新系统上线
- 临时活动、大促、秒杀类
- 系统容量有质变性增长
创业初期最贵的是时间成本，这个阶段用钱堆资源的方式可以快速解决问题，不贸然重构
有些明显的规则要遵守，比如
- 不能硬编码IP，使用域名
- 域名见名知意，区分内外，比如baidu.com / baidu-inc.com
- 区分生产环境
- 避免账号公用

这时候就要拆分了，上面提到的allinone可能已经有了性能、容量等压力。此时就要垂直拆分了
- 核心是基于业务的拆分
  - 代码
  - 数据库、中间件
  - 团队垂直拆分
这时候我们要引入反向代理，最常见的如nginx，我的建议是用更加贴近业务的api网关，比如kong、apisix、openrestry等等，有更多原生功能。如果nginx比作汽车引擎，后者可以比作宝马、奔驰汽车，多了很多配置外，还能开车即用，开箱即用
- 对应反向代理层也需要高可用，好消息是都是必备能力
服务也要拆分，其中关键的是，尽可能无状态，“状态”尽可能让中间件，redis、mysql、共享存储等手段解决，确保服务动态、快速伸缩

这时候，我们引入了新的问题，这部分中间件的性能谁来保证，我的答案是，
- 要有专业的研发、架构师、DBA
- 要使用云上服务，复用云的稳定性，和庞大的技术支持体系（比如备份、同步、安全、审计、扩缩容、无锁变更等等），降低维护难度，回归商业本质
这个时候，随着用户的增加，为了提高访问速度、降低成本。外部就要引入CDN了，针对特定行业，还要引入安全CDN的概念，要有安全属性，把攻击影响降到最低
前后端分离、数据库引入读写分离中间件、微服务架构都可以在这个阶段引入
异步引入，比如计算历史订单，复杂计算，MQ可以对“不关心任务执行结果”，调用链超长，外部三方API。实现削峰填谷，保护下游等等
有些明显的话题
- 引入kubernetes
- 数据库用户拆分，按服务名
- DBA持续优化慢查询过程，添加索引，性能优化
- 以应用为核心的CMDB建设
- CICD流程完善，代码扫描，制品管理，研发效率统计

故障秉持先恢复，再排查
- 通知业务方
- 查看变更，
  - 我们有变更看板，包括
    - 服务发布历史，当前状态
    - 云操作变更-调整安全组、解绑ip、释放资源等
- 配置留痕，比如cp nginx.conf nginx.conf.bak
- 保留证据，截图，日志留存
- 不担心担责，重心是找到根因，避免同类故障再次发生
抽象一层可以解决问题，但更重要的是“如无必要，勿增实体”，血的教训，回头看服务网格技术时，承载了极其有限的需求，但kubernetes集群升级、调整，都需要考虑istio，比如升级前需要先升级istio，性能损失等。
升级策略
- 有维护者时
  - 需要遵循EOL时间
  - 有重大安全隐患
  - 仅新版本提供新功能
- 无维护者时
  - 不做调整
  - 接入waf，依赖waf能力屏蔽问题
  - 人为沟通，产品层面EOL，让产品自然下线
权责对等
- 敏捷团队更加开放，尊重技术选择，更宽松的权限申请，提供必备运维支持（站点监控），敏捷团队要有担责能力
- 统一团队、技术栈，需符合既定规范，仅能申请阶段性有限权限，会自动回收。运维负责第一道响应、扩容、处理
- 非生产环境相对宽松，比如可以在dev环境自行验证服务
- 敏捷统一必选题，不能既要求安全、又要求便利
最大公约数，不使用某家云独占产品
技术服务于业务！