摘要：资源包括什么内存磁盘网络文件描述符外部缓存数据库等，编程语言是如何管理资源的合理的算法架构保证了资源的合理使用，分配内存使用网络等等。
在云计算时代，开发和运维的结合变得越来越重要。在DIFF论坛第一期，前新浪SAE运维主管，郑志勇，分享了《一个开发眼中的运维》根据自己从开发人员转型运维之后的心得，谈如何把在开发上的运用抽象思维方式运用到运维领域。
运维不是打杂的，运维不是客服，运维也不是服务开发的，但要做好合作。
2. 运维是什么？运维服务于整个产品，保证架构合理，系统稳定。运维只对业务稳定负责，所有的工作都是奔着这个去的。
3. 你如何写程序，写程序的目的是什么？程序是为了完成特定的功能。为了完成特定的功能，程序需要申请资源、使用资源、管理资源，功能完成后，还要释放资源。说到底，就是跟资源打交道，和资源打交道的工具是“编程语言”。
资源包括什么？内存、CPU、磁盘、网络、文件描述符、外部API、缓存、数据库等，编程语言是如何管理资源的、合理的算法/架构保证了资源的合理使用，malloc/free分配内存、connec、close使用网络等等。
正确的程序算好程序。
逻辑正确，使用资源尽可能的少；
没有bug，没有把机器资源耗尽；
稳定性好，不会异常退出；
可用性高，有HA方案，不会因为一台机器（或一个进程）无法提供服务，而影响整个系统的服务；
没有单点是基本要求；
容易扩展，只需要简单的增加资源（CPU、内存、磁盘、机器等）就行，不需要太多人工迁数据、修改配置等；
容易维护，包括容易配置、容易部署、容易监控等。
5. 如何写出好程序？什么样的程序不出错？代码少的程序错误少，逻辑简单的程序错误少，需要管理的资源少的程序错误少。要复用代码，减少代码的数量。
要抽象，分层，内聚，解藕，简化逻辑，隔离资源，才能简化逻辑，隔离资源，限制错误。
没有持久状态的程序好扩展，没有持久状态意味着上下线机器不需要迁移数据。没有状态的程序也很容易做HA方案。
配置简单，日志丰富，能提供程序状态查询的程序好运维。
但程序不可能没有数据，通过集中管理数据库，让数据尽量只读，预加载数据等手段隔离逻辑和数据，也能让扩展变的容易。
6. 系统是什么？系统是我们运维的目标，不了解系统是什么，就不知道如何运维。
系统是网络，是机器，是程序。是把网络，机器，程序组织起来的架构。
机器角色应该是尽量单一的，架构应该是数据流简单的，基础业务服务化的。
系统是动态的，运维系统首先考虑的不是当下成本，而是系统变更（扩容，上下线机器）的成本。
运维必需是简单的，要考虑的一个新手，如何能尽快上手工作，而不是冗长的文档和复杂的培训。
7. 写程序和做运维是类似的，甚至一样的！程序提供单一功能，而运维搭建，维护的系统提供全部的功能，开发人员开发的程序只是整个系统的一个部分。从某个角度说，开发人员做的事情越少，系统越容易稳定，因为开源的总是更靠谱。这是减少代码，也是复用。
但运维却理应比开发更不容易犯错，因为运维只需要管理资源，而不需要应对复杂的业务逻辑。
这是个矛盾，因为开发负责的复杂业务逻辑，是运维负责的系统的一部分，前者不稳定，后者也别想消停。
所以运维不懂开发，至少要懂如何控制复杂度，如何隔离故障，如何服务降级。出色的运维人员，只要精通一门语言，必然也是出色的开发（反之亦然）。但什么是出色的运维呢？大部分运维人员，只是一个熟练的操作工人。出色的运维必然更了解系统（原理），这要读很多书，做很多思考，有很多实践。
只看这个cat bigfile.txt | parallel --pipe wc -l | awk "{s+=$1} END {print s}"你能不能想出parallel加速的原理是什么？
CPU高意味着什么？你是不是应该先问问是sys，user，iowait这三个的哪个高？是单个CPU高，还是整体都搞？
你是否了解有的程序CPU使用率90%就有问题了，而有的350%了还没问题？
load高意味着cpu高吗？内存耗尽导致load高的原理是什么？内存耗尽回导致io高吗？
9. 是否正确的监控了资源？监控了磁盘使用率，是不是也监控了磁盘的io能力，raid卡呢？磁盘损坏呢？监控了网卡使用率，是不是也监控了丢包率？
10. 资源是否一定对应硬件？CPU，内存，磁盘，带宽都有对应的硬件，那些没有硬件对应的资源呢？文件描述符，端口数，进程数是不是资源？
路由表，iptables，cron是不是资源？
MySQL主从，第三方REST接口是不是资源？
11. 为什么要尽量把一切抽象为资源？还记得刚才说程序要讲抽象么，为什么linux一切皆文件？一切运维对象都抽象为资源后，就可以用尽量统一的方法来管理（配置，监控）。
如果新上线一台机器无比容易，为什么还要费尽修复删除的/usr目录呢，把它当成新机器重做上线就行了。
线上变更必需走配置管理。线上系统对任何人应该是只读的，只有配置管理程序有权写。这样保证了，变更是可重复的，可复制的。手工加路由，手工修改文件权限，手工配置ip，手工配置nfs，手工起虚拟机等等。一切在线上手工做的操作，于团队都是无益的，因为团队失去了一次改进配置管理的机会。任何操作不是想我就这一台机器，而是想我有1000台机器怎么办。
上线业务必需先问，如何保证HA，如何扩展，如何运维/监控。这三个问题不解决，谨慎上线，当然上线必需使用配置管理上线。
隔离复杂度，要简化，抽象。抽象指角色抽象。运维眼中没有计数用的mc，和缓存用的mc，运维眼中只有mc，于是所有的mc都来自mc池，mc池通过puppet配置，创建mc的过程编程了简单的
puppet配置。一旦把自己管理的所有业务抽象/分拆为几种有限的“业务”，缓存、mysql、httpd等，一切就简单了。例如我们有缓存池、数据库池、redis池、httpd池。（参考:4、5）
先解决问题，然后是以后如何避免此类问题，后者更重要。
不犯第三次错误（重复的问题不出现第三次）。第一次算不知道，第二次算不小心，第三次特么是故意的吧。如果每个问题都能彻底有效解决（最终落实到配置变更和监控），问题就会越来越少。
时刻思考如何“偷懒”，运维越清闲，系统越稳定。
13. 配置管理是如何管理资源的？包，所有线上的软件/脚本都是通过(rpm)包管理的。
文件，所有的变更“持久化”都是通过文件。程序的配置文件，sysctl，iptables，route，cron等凡是能用配置文件控制的一切。
进程，所有的进程都是用配置管理启动的，或者通过配置管理写文件到系统启动目录，例如rc3.d。
你能相到的一切，无论是配置keepalived，还是添加用户，都抽象为这三个。如果不能抽象为这三个，请再思考两个小时。
如果系统可以由这三者全部控制，而这三者又全部写入了配置管理，这意味着按照配置管理配置出来的系统就一定是对的。扩容，升级，机器的上线，下线从此该有多容易。而运维人员，可以通过配置管理，一览整个系统，通过持续改进的模板，配置更容易学习，不容易出错。
的正确性，业务响应时间也要同等关注的。
基础监控要全面，但不一定实时报警。如果业务不受影响，又何必半夜起来处理宕机呢？如果业务有问题，全面的监控会帮你发现问题的蛛丝马迹。
如果memcache偶尔响应慢，你怎么能想到是swap导致的呢？全面的监控可以帮你发现这一点。把业务逻辑抽象为资源，可以统一业务监控和基础监控。（监控如何算全面，参考8、9）
运维技巧重装操作系统，使用puppet重新配置，是系统恢复到正确状态的最佳途径。理论上，新装的机器使用puppet配置后一定是能用的，否则，就是puppet写的有问题。
区分无状态的机器和有状态的机器，尽量把状态集中，然后集中精力运维这些有状态的机器。
宁可通过网络把状态集中也要尽量让机器避免有状态，无状态的机器非常好运维。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/7889.html
摘要：虎牙直播运维负责人张观石张观石，拥有余年网站开发架构运维经验目前关注互联网服务可靠性系统工程运维平台的规划建设网站高可用架构等方面在音视频传输质量评估微服务运维方面积累了丰富的经验。 showImg(https://segmentfault.com/img/bVbjqGq); 虎牙直播运维负责人张观石 张观石，拥有10余年网站开发、架构、运维经验；目前关注互联网服务可靠性系统工程、运维...
摘要：本文是根据虎牙直播运维负责人张观石月日在携手魅族百度云主办的第十三期魅族开放日虎牙直播平台实践演讲中的分享内容整理而成。英雄联盟是全球最大的电子竞技赛事，目前正在如火如荼进行，从今天开始进入了总决赛的淘汰赛阶段了。 showImg(https://segmentfault.com/img/bVblQM9?w=1080&h=720); 本文是根据虎牙直播运维负责人张观石10月20日在ms...
摘要：作者介绍王艺，百度云智能运维架构研发负责人。年转向运维方向，作为智能运维架构方向的技术负责人，致力于为百度智能运维平台和产品提供高性能高可用可扩展的系统架构和基础设施。持续的数据建设，是智能运维建设的关键。 作者介绍王艺，百度云智能运维架构研发负责人。2010年加入百度，先后负责百度链接库、百度志愿计算、百度统一资源管理的研发，经历过千亿级网页链接的洗礼，也调度过数十万量级的服务器，热衷于直...
摘要：当云平台出现网络故障系统故障等问题，这对云租户用户有时甚至是致命的，所以不少是由高级别开发人员转型而来。目前国内各大云厂商也基本都提供了应用运维平台，包括腾讯蓝鲸阿里华为等。 DevOps 全链路 下图是我们熟知的软件研发环节，在迭代频率高的研发组织里，一天可能要经历多次如下循环。对于用户群体庞大或者正在经历大幅业务扩张的企业研发组织，除了重点关注应用的快速上线之外，如何保障应用的高可...
阅读 869·2021-10-13 09:39
阅读 1458·2021-10-11 10:57
阅读 2524·2019-08-26 13:53
阅读 2518·2019-08-26 12:23
阅读 3652·2019-08-23 18:30
阅读 3713·2019-08-23 18:08
阅读 2506·2019-08-23 18:04
阅读 2940·2019-08-23 16:28
