(1)基础运维系统建设的一些见解
基础运维的一些认识
-
运维目标价值: (参考InfoQ:互联网运维的价值体系)
运维目标价值是制定运维规范,搭建运维体系,开发运维系统的基本理念与指导方针.
-
质量(高): 运维质量是指"满足用户需要的程度".
- 可用性: 可用性是衡量运维质量的最基本指标. 可用性就是连续服务时间占总服务时间之比.
- 性能速度: 性能速度是衡量运维质量的很重要指标.
- 用户满意度: 用户满意度是衡量运维质量的关键指标.
-
成本(低): 运维不是直接的效益部门, 但可以通过成本控制产生效益. 成本控制精细化考验运维团队的技术能力和管理能力.
- 服务器角度
- 带宽角度
- 人力角度
-
效率(快): 最终检验运维效率的一个核心指标就是面向业务整体调度和整体交付能力. 这也是运维平台化的最核心目标.
- 故障: 故障发现, 故障定位, 故障处理.
- 资源交付: 服务器, IP, CDN, 数据源等等
- 变更: 扩容, 上线, 迁移等等
-
安全(风险):
安全是互联网产品的生命基线,宜早完善安全相关的制度和规范. 从系统级别、数据级别、应用级别等各个层次规避可能的风险与隐患。特别是数据的安全保护, 应该全局统筹,对数据建立分级体系.针对不同的分级制定不同的管理策略和使用策略，包含帐号密码、日志脱敏、数据隔离、传输加密、以及数据的加密备份等等.
-
-
运维规范化(流程化):
运维规范是运维作业的制度.所有运维系统的用户操作与流程设计必须兼容运维规范(流程). 如果某些领域尚无相关规范或操作流程, 应该联系运维同学共同商榷制定.
- 网络操作规范
- 服务器操作规范
- 帐号管理规范
- 项目部署规范
- 数据源操作规范
- 云平台操作规范
- 其他
-
运维自动化:
运维作业经过梳理与规范(流程)后变成一系列机械化的操作步骤. 借助软件手段(自定义脚本, 开源工具, 运维系统)实现运维自动化. 运维自动化可以实现"成本"与"效率"的部分目标.
-
运维平台化:
-
运维规范化与自动化后, 可以大大降低人力成本, 排除故障隐患, 加快资源交付效率. 但是无法对资源进行综合管理,也没有整体调度/整体支付的能力, 更别说容量规划,成本审计,资源统筹...等等.
-
现代"云"只是运维平台化的一种实践与方向!资源经过虚拟化与服务化后整合到云平台集中管理, 提高了整体调度与快速交付的能力, 也节省了人力运维的成本. 云平台一面"便利", 另一面"炙手":
- 资源隔离成本变高: 不同VPC的资源借助VxLAN隔离, 同一HV的静态资源使用linux用户目录权限隔离, 动态资源使用cgroup,namespace等隔离, 公共集群的资源基本无法隔离. 这些都会直接损耗物理设备的一些性能.
- "类DoS"故障概率加大: 公共集群能够实现"综合成本"目标, 却需要十分小心预防"类DoS"故障, 这就迫切要求云架构中融入"保险丝"的熔断技巧, 避免某个项目或某个用户在某个时刻对集群过高的占用率瘫痪了其他项目或用户的正常业务.
- 安全难度系数加深: 平台的每个环节都可能引入安全"风险". "短板效应"更加深刻!
-
后话
运维系统建设一定是运维同学与研发同学共同合作的成果. 运维同学直接服务用户, 最清楚系统的需求. 研发同学在设计流程或者开发系统的时候, 与运维共同梳理需求, 抽象操作流程. 然后经过:
- 规范化(流程化): 约定操作中涉及的步骤,目录,权限,依赖等.
- 自动化/平台化: 基于规范后的结果设计用户页面,实现功能模块.
这样开发出来的系统才会不偏离需求, 才能更好地协助运维同学实现运维的目标价值.
