邵海杨，UPYUN（又拍云）联合创始人兼运维总监，新浪微博@海洋之心-悟空 ，资深系统运维架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。喜交流，活跃于社区，积极投身于开源活动的组织和传播，真诚待人，授人以渔，共同进步。
目前运维团队只有3枚全栈工程师，负责云存储，云加速，云处理三大组件，通过合理的流程规划和自动化运维思想，不光拥有自己upyun特色的运维平台和工具，也整合了资源管理和人性化的监控报警机制，全面接管upyun 1000+服务器的正常运行。
也许是要经历过苦点累点才能真正体会到什么是轻松和智能后的愉悦吧？这就是人生存在的价值。哈哈，当然这只是心灵鸡汤而已了。但不要过份相信元芳怎么看，只要你肯动脑筋，肯定会有聪明的方法去解决问题，关键是你想成为大多数抱怨的人，还是少数偷着乐的人。
运维确切的说，一方面是因为要掌握和不断学习大量的系统知识，另一方面还要经历多次一线救火排障的非人考验，最主要是要成为“背锅王”后那种淡定后，才能成长为一名合格的运维工程师，从成长过程来看，无论是智力上还是精神上，都是极大的考验，所以我们坚信自己都是修成正果的“斗战胜佛”，都是“千淘万漉虽辛苦，吹尽狂沙始到金“的金子。所以，快乐的秘诀就是好好活着，人生只有一次，别对不起自己。
云是先进的发展趋势，与其担心不如坦然接受。未来的云还是以公有云和私有云并存的局面，一些能力差的鸡肋运维角色的确会消失，但在私有云上，还是需要相关技能人员的，甚至很多做云服务及配套服务的公司也需要大量的运维人才，机遇与风险共存嘛，这也对运维人员提出了更高的挑战。
所以，面对挑战，要转变思路，以前运维要熟悉各种操作系统，各种系统软件的应用，就要要熟悉各种云操作系统，云组件的应用，洞悉先进软件的趋势，其实，只要你每天都坚持学习，必定会功不唐捐。
很多开源系统基础软件都非常优秀，因此常青不衰，所以，不要重复造轮子，多借鉴学习一些优秀的系统软件非常实用。另一方面，在日新月异的今天，我更希望开发人员重视交流能力的培养，多参加社区活动，结交认识不同领域的优秀人才，这样，又能在技能上取长补短，何乐而不为呢。
的确非常美好，但并非不可实现，DevOps跟架构师一样，可以不是一个人的称号，它可以是一个有着互相信任，互促互补的团队的统称，可以一起并肩作战，这在很多公司中都有，关键是你懂得付出和感恩，尊重和被尊重。
这次分享，注意是分享哦，会带来一些云上运维的趋势和思考，更加注重术的领悟，以及一些运维哲学吧。
分享是一种美德，无论各行各业跨界交流，还是世间万物都有因果关系，只要感兴趣和有时间的人，都欢迎一起来交流，事实上，每次的分享，我的收获不比别人的少，非常感谢大家的思想火花上的碰撞。
A: 我们现有的标准化也是从“接盘侠”做起的，所以起初也是根据之前的遗留情况具体分析，具体应对，通过定制升级脚本（测试升级流程无问题后再批量），目的就是通过持续的改进，最终实现平台一致性。所以标准化的过程是个互相协商妥协的交流过程，操作过急并不可取，稳中求胜才是第一位。当大家磨合一段时间了，后续的项目再做标准化就非常顺利了，如果真遇到项目赶的时候，还是要遵循“先完成，再完善，后完美”的原则，只要不是严重拖延症患者，标准化并不会花费太多的时候和精力，但是换来的效益是最大的，一定要有防微杜渐的前瞻意识。
A: 使用gitlab来保存变更代码，做到追溯可寻，所有人公用一个代码仓库，保证入口准确和唯一；做到一次编写，到处运行，所以bash/sed/awk的脚本语言移植性极佳，人员互备性也好；使用文本来保存信息，可读性和移植性有保证；快可以，但要懂得何时停下来，稍作休整，把不足弥补消化，切记不要日积月累；
A： 又拍云其实做的是SaaS服务，旨在面向移动互联提供服务至上的一家集云存储，云分发，云处理一站式的云服务公司。
A： 又拍云采用的是基于erlang并发语言，参考了Amazon的高可用Dynamo模型，使用KV模型来存储多副本数据对象，同时还提供了目录检索服务，基于RESTFul的API调用，上面还提供了有来自于官方及网友贡献的各种语言的SDK封装。
A: Dynamo高可用存储模型本身就是设计成多副本存储，P2P哈希一致性，保证数据存放在不同的服务器和不同的磁盘上；机房目前采用了同城异地+裸光纤直连做灾备，多机房多数据中心已经在开发中。
A: 在线热部署热升级的秘密在于“尽量保证无单点+热加载技术”，如使用DNS轮询，LVS负载均衡，Nginx热升级，ATS cluster，Redis master/slave多级缓存。
A: 我不太明白你的同步延迟要求有多大，但我曾经设计过Haproxy/LVS+Mysql主从架构，用于彩票读写密集型场景，采用了Mariadb+Xtradb+SSD，性能和效果还是不错。据说最新的Mariadb底层服务框架和Xtradb/Tokudb性能都不错，可以测试一下。
A: 前面加一层负载均衡，如LVS,Haproxy，都是不错的选择。
A: 没有使用过，如果是自有应用，源码在自己掌握中，我还是建议从程序级别去区分读写请求，效率最高。这跟公有云开放提供给第三方开发者的数据平台是不一样的设计场景，平台的智能化是指降低开发者的门槛，所以，开发者不需要了解读写分离或分库分表的高深技巧，也能享受平台带来的可扩展性优势，但势必会带来一些解析上的开销，所以要权衡利弊。
A: 可以参考阿里的Amoeba或者 360 Atlas
A: 基于机械磁盘结构的数据库前面都要加层缓存，用于存放热数据，提供给程序调用，如memcached,redis；后端数据库最好有主从读写分离；有条件的话，可以采购一块SSD，利用flashcache/bcache技术给sata磁盘做个热区；利用慢查询工具做好查询语法的检查；如果对实时性，如事务一致性要求不苛刻，可以使用如Mongodb这样的NoSQL新型数据库；
A: 如果你已经使用了消息队列+生产者/消息者解决方案，其实整个架构已经具备了可扩展性，理论上可以通过加机器扩展消息队列集群，加机器添加生产者和消息者角色，从而线性扩展处理能力。如果研究再深入些，就是里面的数据如何压缩，如何设计成更加小巧有效，如何提升带宽吞吐率。如果压力还要再大大，就要从设计上保证消息队列也可以按业务做垂直划分。
A: 我不是数据库专家，除了用慢查询来排查问题，目前没有什么值得炫耀的技能。
A: 这是个美好的未来，我们要勇敢接受这样的挑战和变化。与其在想询问别人的看法，不如现在就行动起来，答案是肯定的。
A: 以往运维的工作就是部署环境，发布上线，监控排错以及处理各种疑难杂症，因为身处一线和最后防线，感觉总是在救火，吃力还不讨好。因此我们要转变角色，掌握主动权，如：运维自动化（开发运维平台，操作封装成web接口，实现角色分离，权限分离，操作日志记录，让开发人员也可以自主上线发布，可追溯），监控常态化（编写监控脚本，实现自动报警，自动隔离故障，为运维团队争取缓冲时间， 尽量避免限时实时处理），性能可视化（如全国地图的业务指标显示，性能展示，瓶颈点，利用这些数据可以显而易见的让每个人了解实时状态，也能提供争取资源的依据），要做好以上几点其实都离不开开发功底，同时又需要对运维的深刻理解，所以，我们要有这个理念，朝着这个方向努力做好，那我们就可以驾轻就熟的玩转运维。
A: 这个范围太大了，我没有能力回答这个问题。
A: 好的，举个例子，如果我们要在nginx阻止某些恶意链接，我们只需要做二步:
秘密在于config这个函数！
config(){ ## block bad url sed -r -i '/#badurl/d' $NGINX_DIR/badurl.conf STRING="" for i in $NGINX_BAD_URL;do echo "$i"|grep -q "^#" [ $? = 0 ] && continue STRING=$STRING"\tlocation /$i/ {\t\t\t\t#badurl\n\t\treturn 444;\t\t\t\t#badurl\n\t\taccess_log off;\t\t\t\t#badurl\n\t}\t\t\t\t\t\t#badurl\n" done echo -e $STRING >> /tmp/.xxx sed -r -i "/block bad url/r /tmp/.xxx" $NGINX_DIR/badurl.conf rm -rf /tmp/.xxx }
A: 循序渐进，掌握尺度很重要，尤其是在已经稳定运行甚至盈利的系统上，大刀阔斧的革新并不适用，建议先找出性能瓶颈点，重点突破，先赢取团队信任，然后再逐步升级改进； 坚持 “先完成，再完善，后完美”，项目也是“先能用，再好用，后用好”的实施方针，包括监控指标和运维平台亦是如此，内心不要被一些困难或者一时的挫折打败，只要坚定方向正确，实施有序，未来肯定是越来越好。
A: 老实说，抽象业务模型需要丰富的实战经验，如果经验不足，还是要虚心多请教前辈，从前人踩过的坑里获取教训。如果你有不同的服务器环境，我建议可以用puppet/saltstack/chef等跨平台部署工具来维护，也可以关注docker这个新兴的项目，后续可以直接在统一的平台上用docker来虚拟化多平台应用，也是一种另辟蹊径的运维思路。
A: 运维工程师必须要掌握bash/sed/awk三剑客编程语言，并且能够灵活应用各种linux基本命令。但是你不能止步不前，为了迎接DevOps的挑战，你还需要多掌握一门语言，我推荐是Python/Nodejs，可以一举多得，打通前后端。
A: 出错日志，监控图，如果架构上没有单点故障，还可以保留现场提供调试。
A: 我们说在做架构的时候，除了高并发，高性能，高可扩展性，还要考虑隔离机制，就像汽车一样，有油门加速，同时也需要刹车，当遇到紧急情况，宁可慢一点也不要撑爆。如在解决在线大并发请求的时候，我们建议是松耦合，引入消息队列+任务分发框架，化并发无序的请求为有序的请求，再通过可方便水平扩展的消费者来实现并发处理。
A: 《鸟哥的私房菜》
A: nodejs考虑到需要回调，因此会有一些内存持久消耗，建议用在短连接应用上，越早释放内存越好，内存占用越小越好，不适用复杂耗时的复杂逻辑查询或者IO密集型应用。如nodejs+redis/memcached/mongodb/kv搭配就比较出色，如果要做复杂查询，建议通过消息队列，或者redis这样的缓存，与后面的关系型数据库松耦合。单进程可以通过node-cluster模块获得多CPU的绑定，性能也能得到提升。
A: Redis 支持多级缓存和主从复制，我们用得最多的也就是多级缓存，基本上3～4级可以保证够用了。
A: 除了bash/sed/awk外，不二之选就是python,其次推荐用nodejs/ruby
A: 话题太大，难于概全，我建议考虑的第一因素，是怎么消灭单点故障，先做到这一点，就能够让你临危不惧，争取时间，才能有精力和时间去消灭更多的性能瓶颈，慢慢完善，架构就是一个不断演变进化的过程，没必要十全十美再上线。
A： mongodb吧
A: 用erlang吧，天生就是并发的，尤其是在电信领域，原生支持二进制传输。
A: 这方面的经验太少了，抱歉无法回答。
A: 运维自动化方面的工具有很多，puppet,chef,saltstack,ansible都是佼佼者，没有绝对好用的银弹，只有灵活应用的高手，所以，多比较再选择。比如说，你的环境中维护的服务器版本各异，跨度很大，那用ansible就比较简捷，因为它不需要安装任何agent,直接基于ssh管理。
A: 无论什么样的云存储，包括私有云，公有云也好，一定要知道关注的指标是什么，如高可靠性，高可用性，高性能，高可扩展性，或者安全性。如高可靠性，就需要多副本模型，如ceph,swift等；高可用性，就要用p2p的哈希模型，如riak；高性能的，就要用KV模型；高可扩展性，也要用p2p的KV模型，最好能够提供RestFul的接口，利于水平扩展；至于云安全检测，可以寻找乌云的有偿服务，物有所值。
A: zabbix，cacti，nmon都可以提供直观，高效率的性能监控。
A: 代码级别的读写分离意义在于前瞻性和扩展性，跟后面到底是一台还是多台透明无关，我们所说的架构设计就在于细节的把握，假设你已经事先做了代码级的读写分离，也许你最初用不上，一旦业务量上来后，成败在此一举的时候，你部署好数据库主从+负载均衡，只需要改变一行代码中的一个端口，立即就能轻描淡写的化解读写压力，这才是高明之处，让人目瞪口呆，同时也让老板对你刮目相看的最佳机会。
A: 只有能从痛苦，重复的工作中，寻找聪明的方法来突破重围，与他人协同沟通共同解决问题的人，才能真正为之着迷而坚持不懈的奋斗，才能从中得到乐趣，这也是公司希望得到的人才。所以，方法比拼命更重要，何况还不拼命，这样的人趁早劝退，免得避免整个团队的效率。建议看《极客与团队》《暗时间》。