监控系统、日志系统、配置管理系统以及部署系统
以前公司在监控、日志分析、应用配置和部署的工作方面都是徒手操作，若将徒手变为自动化，对于上流的互联网公司都急切需要这些自动化管理系统。无数生产的问题以及生产效率的问题都是因为监控、日志、配置以及部署所造成的。做这些自动化管理的系统需要投入大量人力和物力，而且还要专心致志做相关研究才能将这些系统做完做好。
思考下这些系统的做法以及会使用到的相关技术：
监控系统
监控系统很好理解，它的作用是监控线上系统的运行状况，如果线上系统发生问题，那么监控系统会将问题及时的通知到每一个相关的人员。小公司这样的工作是一个半自动化的状态，很多工作还是需要大量人力的投入才能完成，但大公司的监控系统已经实现了监控自动化，虽然大公司的系统比小公司的多的多，但是他们监控的人力的成本却是少之又少。大型互联网公司的系统往往是成百上千，服务器则是成千上万，因此自动化的监控绝对不是看不到产出的而一定是可以实实在在创造价值的。
对如此庞大的资源进行监控，需要考虑很多，首先要定义一些监控的维度，一般最大是系统级别，其次是系统下的功能模块，再细点就是方法层面的，在实际的开发中，一般会从功能模块和方法上控制，这些控制好了，系统级别的监控也就相应的做到了。一般这种监控肯定也是会使用到打点的技术，也就是在程序合适的地方引入监控程序，当系统运行出现异常的时候，监控程序会及时的将信息传递到监控的服务器，服务器将这些问题记录下来后通过短信，邮件的方式通知给相关人员。方法级别的监控比较好做，只要监控程序捕获到了程序运行的异常就行，而功能模块的监控则是需要相关人员定义一套捕获规则，当功能模块触发到不符合规则的地方，监控系统就会给相关人员发出警报，监控的实时性可以达到秒级，效率是非常高的。监控系统做的要人性化，所有的操作都可以在一个Web的管理系统里完成，这个管理系统也是用了大量的可视化图表的方式，直观且易于操作，同时还有相关的绩效管理功能，实在是非常的强大。
日志系统
通过日志查找线上系统的问题，这是解决生产问题的唯一方式，但是对于查看互联网系统的日志是一件非常痛苦的事情，因为互联网的系统几乎没有单点，都是分布式的，所以查看日志的时候就需要查找很多台服务器，如果碰到程序本身的日志写的不太合理，那么查问题几乎是一件大海捞针的事情，此外，在公司里，生产环境往往都是被严格的管理起来的，只有很少数的人可以直接查看生产日志，一般人员想看生产日志常常会有一大堆冗长的审批过程，这些审批过程保证了生产系统的稳定性和安全性，但是恶果就是严重拉长了问题解决的时间，那么如果有一套实现办公自动化的日志系统那就是非常棒的一件事情了，大公司就自己研发了一些这样的日志系统，它的日志系统定义了一套日志的规范，应用系统的开发人员可以按这个规范打出日志，该系统除了能打出符合日志规范的日志，还能将应用系统自身的日志拉到日志系统里，这些日志的查看不再是通过命令行在控制台里看，而是由专门的Web系统来进行查看，他们的Web系统做的挺棒的，可以分组分类的查看相关系统的日志，这些日志在规定的时间里会自动刷新，同时使用者也可以在Web系统里像控制台那样实时的查看相关的日志，只有有相关查看日志权限的人，随时随地不受限制的查看到系统的运行情况。日志系统的设计上某些地方和监控系统类似，也要做到非侵入式，尽量降低系统对生产系统的影响。比较特别的是，在Web系统里看到日志并不是保存在生产系统上的日志，而是存放在日志系统里的日志，也就是说该日志系统会实时的同步生产系统的日志，这种同步不是盲目的，而是会根据一个的规则同步到日志系统，这种规则可以保证在Web系统里很容易定位到那个系统，那个功能模块的日志。大量日志存储绝不可能用关系数据库完成，那么想高效的查询到日志就得使用搜索技术，使用solr进行搜索的。当然保证日志集群的可靠性，zookeeper就得上场了，zookeeper已经是做分布式系统不可避免的技术了。
统一配置系统
系统的配置一般是指将一些环境的参数，系统的参数或者是某些会经常变化的信息用一种特殊的文件保存起来，这样利于系统的维护和扩展，java里通常使用xml文件和properties文件存储配置信息，而那些会经常改变的信息通常会使用properties文件保存，这种配置管理方式对于规模不大或者变更很少的系统而言十分有效，但是对于互联网公司的大型系统以及一些关联度很高的系统而言，当系统运维到一定程度，配置文件可能是最让人沮丧和痛苦的事情，特别是维护它们的方式是通过人力的方法，其潜在的风险也是非常之大的。zookeeper一个重要特性就是配置管理，一些大公司实现的统一配置系统就是通过zookeeper来实现的。统一配置系统同样也是可视化的，使用者不用直接到生产机器上修改配置，重启服务器，而是直接在Web管理系统里操作，配错了可以修改，也可以进行回滚。
自动化部署系统
生产部署是一个项目的最后一步，也是压力最大、风险最高的一步，如果最后上线部署失败了，这种感受就犹如进行了一次辛苦的长跑，眼看就要到达终点了，没想被一块大石头绊倒了，甚至还会掉到坑里，最后还要挨领导批，那滋味可不好受。
小公司系统部署的问题很多，不同的环境，如：开发环境、测试环境、伪发布环境和生产环境，开发环境和测试环境对开发人员来说可以控制，这个操作调试都很方便，这个都比较好。但开发环境和测试环境同伪发布环境同生产环境基本上是完全隔离的，而且不同环境之间的环境配置，系统配置等等都存在或多或少的差异。经常发生，测试环境运行好好的程序到了伪发布环境就出现问题，更揪心的是，测试环境和伪发布环境都没问题，上了生产出问题了，而且是环境造成，这就使每一次部署操作都是小心翼翼的，部署后任然还要投入大量的人力和时间进行监控和测试。
大公司的环境其实比小公司的还要复杂，它们甚至在伪发布环境和生产环境之间还有一些仿真的环境，还可进行灰度发布。仿真的环境是可以直接从生产上摘取一个服务器，部署新开发的程序，让相关人员进行测试验证，而且部署环境的切换也是有专门的Web系统进行管理，不同环境之间可以做到平滑的过渡。这样部署操作不仅是安全性以及在效率上都有很大的提升。
总结
大公司一般有几千名的开发人员却只需要20几个运维人员，因为有强大的开发团队可以支撑内部管理系统的研发，内部管理系统的监控和运维作用，加大了应用系统的稳定和容灾，这就大大减少了运维人员的工作量。
由此可以看到互联网的技术远比传统的企业软件复杂的多，互联网的技术基本都是分布式的，因此线程、进程、通讯、分布式技术以及分布式的可靠性是十分的重要。上面描述的这四种系统，也不是大公司自创的，也是大量借鉴与美国牛叉的大型互联网公司，例如facebook，谷歌等等。
----------------------------------------------------------------
BAT级别的公司都定制自己的监控运维工具，一般公司使用开源的就足够了，常用的开源工具：
监控：ganglia, nagios, zabbix, zenoss...
日志：logstash, flume, sentry...
配置管理和自动化：puppet, chef, fabric, rundeck...
持续交付：本书提到了许多提高系统开发质量的方案。
51cto有个杂志叫 linux运维趋势，也介绍了此方面的内容，可以参考学习
-------------------------------------------------------------------------------