【海量运维、运营规划之道】大系统小做
大系统要简单做、小做，基本原则。
更新历史
- 2022.11.26：完成初稿
读后感
这本书把运维运营的整体架构给梳理得比较清楚了，一系列表格都是精华！
读书笔记
具体工作如下：
- 运营规划，提供运营综合规划支持，分析业务发展需要的资源趋势，规划 IDC 资源，驱动实现并与运营预算对齐
- 运营预算，负责维护产品设计预算、带宽预算、专线预算的申请和滚动更新，并对运营预算结果和运营成本负责
- 运营支持，负责运营服务器的日常管理与相关系统的信息变更管理；负责访问策略、域名管理、IP 管理等基础运营支持
- 系统运维，负责产品运营服务器的系统运维、系统监控与安全保障、系统性能分析和优化等工作；随时待命，处理产品可能遇到的问题，以及突发事件管理
- 应用运维，负责业务的部署、新版本的发布、服务端的变更；负责监控业务的运行撞库，及时处理业务运行中出现的故障，保障业务服务正常可用
- 运维需求，负责与各开发项目组的日常沟通交流，接受并处理项目组提出的运维需求
- 运营数据分析、挖掘，负责产品的业务数据分析与挖掘、性能分析与系统优化、问题跟踪与管理、负责定期给出业务运维状况报告
- 运营流程、规范、制度，负责产品运维流程的探索、产品运维工作范畴与深度方面的文档建设，进行与运维相关的新技术研究；负责系统运维的知识管理体系、流程与文档建设
- 运营接口、平台、培训，负责承担部门内的运营/运维技术培训；负责公共类运维支撑平台的建设和在部门内推行；负责与外部门的交互，包括外部信息对内的知会、内部需求对外的反馈
质量
大系统要简单做、小做，基本原则：
- 高性能、高负载系统必须静态和动态部分分离
- 系统分层设计，模块高内聚，模块间低耦合
- CDN、定制 Web Sever、ISP 细分、LVS = 好的用户体验
- Cache 能够多层、充分、灵活、正确使用 = 大流量、高并发
- 绝大部分网站瓶颈会再数据库上
- 尽可能考虑硬件层、系统层、数据库层、应用层、网络层单点
监控
底层监控
应用监控
数据库监控
告警
成本
