1、From no ops to noops――新浪微博稳定性工程团队运维实践

FromNoOpstoNoOps--新浪微博稳定性工程团队运维实践首先，你得发自内心的愿意伟大我们是谁？•DevOps@Sina •･Lamp项目托管平台•･已托管项目500+ •･日均请求10B+我们是谁？•･每年新增PHP项目100+•･3000+台前端服务器100亿+Hits/天•･45000+⾏行虚拟主机配置30G代码（GZip后）•･3000+台数据库服务器200亿+数据库请求/天运维演变进程•･平台化阶段 •･运维⼯工具发展阶段 •･自动化运维萌芽阶段 •･自动化运维发展阶段平台化阶段•･建立统⼀一的标准与规范•･简化操作与维护•･统⼀一监控与问题修复•･抽象服务器拓扑与部署情况ProjectAUsersDeveloperProjectBUsersDeveloperProjectCUsersDeveloperUsersDeveloperUsersDeveloperUsersDeveloperVhostAVhostCVhostBPlatformDistributionService平台化阶段问题•･HTTP调用也能引发灾难•･服务互相影响恶化小项目故障•･曾尝试使用限制每虚拟主机的进程数来解决问题通用TCP透明代理AAProxy•･目前只⼯工作于HTTP协议•･类滑动窗⼝口流量控制•･ToDo：•･DNS异步解析•･对非HTTP协议支持•･热点内容Cache与性能优化应用CGroup•･解决单服务器资源抢占的“明星”解决⽅方案•･是否需要同时引⼊入LXC？•･⽆无CPU抢占时？•･⼀一并解决各应用资源使用统计问题RESTfulAPIStatisticServiceWebConsoleNginx-basedL7Loadbalancer:8082VHostBStatisticalData:8081VHostA:8083VHostC-ZRequeststoVHostA-Z:80RequeststoVHostA:8081RequeststoVHostB:8082RequeststoVHostC-Z:8083cpu.shares=400,cpuacct,memorycpu.shares=200,cpuacct,memorycpu.shares=50,cpuacct,memory运维工具发展阶段•･为服务器按照功能划分为多个角⾊色•･每个角⾊色包含多个模块，每个模块维护统⼀一的配置⽂文件•･根据之前经验，差异由系统维护最为合理•･CFEngine管理⼀一切•･差异配置怎么办？httpd-vhost.conf_tmplvhost_config.plFENode/etc/httpd-vhost.conf没有配置文件的服务怎么办？•･那就创造⼀一个配置⽂文件吧～•･当然要创造⼀一个全局的～•･索性与监控程序结合起来怎么样？•INIVSYAML •･就比如Memcached![MBlog_Userinfo]ip=10.55.22.100:1000010.55.22.101:1000010.55.22.102:1000010.55.22.103:10000memsize=10.55.22.100:1G10.55.22.101:1G10.55.22.102:1G10.55.22.103:1Gconn_limit=10.55.22.100:1W10.55.22.101:1W10.55.22.102:1W10.55.22.103:1W[MBlog_Counter]ip=10.55.22.100:1000110.55.22.101:1000110.55.22.102:1000110.55.22.103:10001memsize=10.55.22.100:1G10.55.22.101:1G10.55.22.102:1G10.55.22.103:1Gconn_limit=10.55.22.100:1W10.55.22.101:1W10.55.22.102:1W10.55.22.103:1Wmc.confMCNode/etc/init.d/memcached/etc/cron.d/check_mcMonitorNode/etc/monitor.d/check_mc.pyReportingNode/etc/reporting.d/get_mc_stats.pyMakeDisastersManual足够自动化了吗？•･运维⼯工程师与开发⼯工程师思路的区别•･运维是⼀一个体系•･由许多相关联的部分组成•･系统扩展性不好•･⽆无法灵活的联系各个点Framework我们发现问题在出发点•･自动化运维不是“另⼀一个”系统•･它是对你架构可运维性的更⾼高要求•･需要将可运维性作为软件和架构设计的主要考量因素之⼀一•･运维⼯工具也是软件和架构的⼀一部分RevolutionOfMartyredElitesit’sROMEAssetInventoryWorkflowComponentsServicesConfigurationManagementOrchestrationDataStorageAPINamingMonitoringDatabaseLogging….Web1UIMobile1AppOaaSAPIs灰度发布RequestsMANAGEMENTPRODUCTIONRESTfulAPIStatisticServiceWebConsoleLVS-basedFullNATNginx-basedL7LoadbalancerFront-endsMachedRequestsOtherwiseRuleManagementTestDeploymentStatisticalDataTEST-WEIBOgroupDEFAULTgroup基于Ansible•･每个模块只完成较为单⼀一的功能•･模块之间通过API进⾏行通讯•･为什么不用Puppet？•･为什么需要WebUI？•･有了WebUI为什么还要API？基于Ansible•･通过模版引擎解决配置⽂文件管理•･在Role中定于各种基础操作：装包、执⾏行命令、分发配置⽂文件等•･可使用Group来进⾏行继承•･曾经尝试过SaltStack•･目前为⽌止，Ansible具有让我们满意的扩展性我们用了什么技术？•HTTP-basedRESTfulAPIwithJSONpayload•AvarietyofMongoDB-likeCRUD•Python•MongoDB谢谢Q&A@陈尔冬