|
|
知识路径： > 大型网站运维 > 大型网站也背景知识 >
|
|
相关知识点：9个
|
|
|
|
|
我们定义的大型网站，服务器规模大于1000台，PV每天至少上亿（至少国内排名前10），如Sina、Baidu、QQ、51.com等；其他小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合型人才”，如有些公司把一些采购合同都纳入了运维职责范围，还有如网络规划也纳入运维职责。所以，运维对其他关联工种必须非常了解熟悉：网络、系统、系统开发、存储、安全、DB等。
|
|
|
|
为了了解和大型网站相关的技术，首先要了解大型网站的产生过程。
|
|
|
|
（1）首先公司管理层给出指导思想，产品经理定位市场需求（或复制成熟应用）进行调研、分析、最终给出详细设计。
|
|
|
|
（2）架构师根据产品设计的需求，如PV大小预估、服务器规模、应用架构等因素完成网络规划、架构设计等。
|
|
|
|
（3）开发工程师将设计code实现出来、测试工程师对应用进行测试。
|
|
|
|
（4）运维工程师进行运维。首先明确一点，前三步与运维关系很大。应用的前期架构设计、软／硬件资源评估申请采购、应用设计性能隐患及评估、IDC（Internet Data Center）、服务性能、安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装。运维工程师还需要对上线的应用系统架构是否合理、是否具备可扩展性及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复始：需求→开发（升级）→测试→上线（性能、安全问题等之前预估外的问题随之慢慢体现出来）；应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化、随着应用PV增减进行应用架构的伸缩、安全等。
|
|
|
|
|
|
（1）尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等），提高效率。
|
|
|
|
（2）解决现实中服务存在的问题，如高可靠性、可扩展性问题等。
|
|
|
|
（3）大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改或运行指定任务；2000台服务器如何快速安装操作系统；各分布式IDC、存储集群中数PT级的数据如何快速的存储、共享、分析等一系列挑战都需运维工程师的努力。
|
|
|
|
在此说明一下其他配合工种情况，在整个项目中，前端应用对于网络／系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络／系统架构方面事宜，当然软／硬件采购人员等事业部其他同事也不会关心这些问题，各司其职，但项目的核心是运维工程师！他是其他部门的桥梁。
|
|
|
|
运维工程师的职责，就是“确保线上稳定”。看似简单，但实则不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上bug隐患、运维自动化管理程度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增长带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。
|
|
|
|
各公司业务方向不一样，会导致运维模式或方法都不一样，如51.com和baidu运维肯定区别很大，因为它们的业务模式决定了其架构、服务器量级、IDC分布、网络结构、通用技术都会不一样，主打新闻门户的Sina与主打SNS的51.com运维模式差异就非常大，甚至职责都不大一样；但有一点，通用技术及大致架构上都大同小异。
|
|
|
