系统管理员模式---google运维连载
系统管理员模式---google运维连载
今天跟大家讨论一下google运维，说一下系统管理员模式
雇佣系统管理员，因为复杂的计算机系统是行业内一直以来的普遍做法，这些系统管理员负责将现成的软件组件，不属于生产环境中，对外提供某种业务服务系统管理员的主要工作，在于应对系统中产生的各种需要人工干预事件，以及来纸业务部门的变更需求，随着系统变得越来越复杂，组件越来越多，用户流量不断上升，相关的事件和变更需求也越来越多，于是公司需要招聘更多的系统管理员来应对日益增多的事件系统管理员的日常工作。与研发工程师相差甚远，通常分属两个不同的部门开发部和运维部
这种模型具有许多优势，对新公司来说，这种模式在行业内具有广泛的应用案例可供参考，市场上具有相关从业经历的人也很多，招聘相对容易，很多第三方工具厂商及系统集成厂商都有现成的工具和软件解决方案，帮助一个相对初级的系统管理员团队应对简单的系统维护操作，但是很少有人提及这一页做以及相应造成的 deV/ opS分离的团队模型存在一些无法避免的问题，我们要从两个方面来阐述。
第1直接成本
直接成本相对清晰，因为系统管理员团队大部分依赖人工处理系统维护事件以及变更的实施，随着系统服务长度的增加部署规模的扩大，团队的大小基本与系统负载呈线性相关共同增长
第2间接成本
研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了。但是这些间接成本往往大的多从本质上来说，由于研发团队和运维团队背景各异，技术能力与工具使用习惯上差异巨大，工作目标也截然不同，两个团队对产品的可靠程度要求，理解不同，具体执行中对某项操作的危险程度评估与可能技术防范措施也有截然不同的理念，这些细节上的分歧累积起来，最后逐渐演变成目标与方向上的分析，以及行政内部沟通的问题，甚至最后上升的部门之间的信任与尊重层面，这样的情形是谁也不愿意看到的，但却是时时上演的.
期待连载哦
页:
[1]