前不久我们公司和业内一家一流的公司做了一次技术交流，对于他们的监控系统、日志系统、统一配置系统以及部署系统印象深刻。深刻的原因是我们公司这些工作都是徒手操作，跟他们相比简直是大刀对坦克了，交流完后我们大伙内部也讨论了下，该公司的这些系统我们这边也是急切需要的，无数生产的问题以及生产效率的问题都是因为监控、日志、配置以及部署所造成的，但是现实是做这些自动化管理的系统需要投入大量人力和物力，而且还要专心致志做相关研究才能将这些系统做完做好，而我们技术部门现在人力远远不足的时候这样的系统开发对于领导而言是会影响核心业务开发的，领导绝对不会让我们这些开发人员投入大量精力去做这样的事情，如果不是全身心投入的，那又怎么能做出好东西来哦。其实大伙都很想做这些，就是有劲使不上，本质还是我们公司实力不够，没有这家公司那么多的开发研发的资源。
这些系统一定是每一家成熟的互联网公司都会去做的，因此我今天想根据和这家公司的交流的回忆，思考下这些系统的做法以及会使用到的相关技术，因为我没做过这些系统，只能是靠回忆和自己的理解进行描述，如果有错误的地方还请大家多多包涵哦。
首先是监控系统，监控系统很好理解，它的作用是监控线上系统的运行状况，如果线上系统发生问题，那么监控系统会将问题及时的通知到每一个相关的人员。我们公司这样的工作是一个半自动化的状态，很多工作还是需要大量人力的投入才能完成，但是与我们交流的公司的监控系统已经实现了监控自动化，虽然该公司的系统比我们多的多，但是他们监控的人力的成本却是比我们少之又少。大型互联网公司的系统往往是成百上千，服务器则是成千上万，因此自动化的监控绝对不是看不到产出的而一定是可以实实在在创造价值的。如果我们想对这么庞大的资源进行监控，那么我们就得要去考虑怎么进行监控了，我想这种监控应该首先要定义一些监控的维度，一般最大是系统级别，其次是系统下的功能模块，再细点就是方法层面的，在实际的开发中，一般会从功能模块和方法上控制，这些控制好了，系统级别的监控也就相应的做到了。一般这种监控肯定也是会使用到打点的技术，也就是在程序合适的地方引入监控程序，当系统运行出现异常的时候，监控程序会及时的将信息传递到监控的服务器，服务器将这些问题记录下来后通过短信，邮件的方式通知给相关人员。方法级别的监控比较好做，只要监控程序捕获到了程序运行的异常就行，而功能模块的监控则是需要相关人员定义一套捕获规则，当功能模块触发到不符合规则的地方，监控系统就会给相关人员发出警报，与我们交流的公司这些都实现的不错，而且监控的实时性已经达到了秒级，效率是非常的高的。谈到打点，知道打点技术的人都会有一种担心，这个打点会不会影响到业务系统的运行了，在监控打点将信息传递到服务端时候，会不会挤占一定的网络资源，打点技术无法避免这些问题的发生，而最优的解决方法就是让这些影响降低到最小，并不是因为有这个问题而抛弃打点的方式。该公司怎么解决的，我现在记得不清楚，但是我自己思考解决这样的问题无非有两种（针对java）一种是多线程，一种是RPC的方式，RPC可以说是一种进程的方式，我个人觉得线程的侵入性要强于进程的方式，如果是我去实现，我应该会用RPC的方式，因为RPC占用线上系统的资源比较少，它的开销主要是在监控服务端本身以及网络资源，而且我们很容易控制RPC所占用的宽带资源的比例。互联网公司的系统应该都不会有单点的系统，都会用分布式来实现，而监控系统需要管理那么多的系统和资源，所以它本身的分布式系统的可靠性要求就非常的高，该公司这边解决分布式可靠性的问题是通过zookeeper或者借鉴zookeeper的原理自己实现的一套机制，这次分享我深切感受到zookeeper技术的重要性了，zookeeper我今天就不展开讨论了，我后面会重新研究下zookeeper，等研究好了，我再专门写一篇文章。监控系统还需要一个很重要的功能就是自动化部署，这点也是非常关键的，可以想象下一个拥有成百上千个系统，成千上万服务器的公司，如果监控系统不能实现自动化部署，避免过多人力介入的办法，那么做出来的监控系统可能还没能体现到自身价值之前，就开始为每个应用系统埋下了定时炸弹，可惜本人没有参入过多的系统运维的工作（因为我现在在公司是专职前端）所以我不清楚业内一般是如何做到这点，我只能想象一下，是不是就是使用一些能做批量部署操作的shell脚本就行了。与此同时该公司的监控系统做的也非常人性化，所有的操作都可以在一个Web的管理系统里完成，这个管理系统也是用了大量的可视化图表的方式，直观且易于操作，同时还有相关的绩效管理功能，实在是非常的强大。
下面我再说说日志系统，通过日志查找线上系统的问题，这是解决生产问题的唯一方式，但是对于查看互联网系统的日志是一件非常痛苦的事情，因为互联网的系统几乎没有单点，都是分布式的，所以查看日志的时候我们就需要查找很多台服务器，如果碰到程序本身的日志写的不太合理，那么查问题几乎是一件大海捞针的事情，此外，在公司里，生产环境往往都是被严格的管理起来的，只有很少数的人可以直接查看生产日志，一般人员想看生产日志常常会有一大堆冗长的审批过程，这些审批过程保证了生产系统的稳定性和安全性，但是恶果就是严重拉长了问题解决的时间，那么如果有一套实现办公自动化的日志系统那就是非常棒的一件事情了，这里我还是想说我认为这样系统是实实在在有产出的，是提升公司能力的一个重要手段。与我们交流的公司就自己研发了一套这样的日志系统，它的日志系统定义了一套日志的规范，应用系统的开发人员可以按这个规范打出日志，该系统除了能打出符合日志规范的日志，还能将应用系统自身的日志拉到日志系统里，这些日志的查看不再是通过命令行在控制台里看，而是由专门的Web系统来进行查看，他们的Web系统做的挺棒的，可以分组分类的查看相关系统的日志，这些日志在规定的时间里会自动刷新，同时使用者也可以在Web系统里像控制台那样实时的查看相关的日志，只有有相关查看日志权限的人，随时随地不受限制的查看到系统的运行情况。日志系统的设计上某些地方和监控系统类似，也要做到非侵入式，劲量降低系统对生产系统的影响。比较特别的是，在Web系统里看到日志并不是保存在生产系统上的日志，而是存放在日志系统里的日志，也就是说该日志系统会实时的同步生产系统的日志，这种同步不是盲目的，而是会根据一个的规则同步到日志系统，这种规则可以保证在Web系统里很容易定位到那个系统，那个功能模块的日志。大量日志存储绝不可能用关系数据库完成，那么想高效的查询到日志就得使用搜索技术，而对方使用的是solr进行搜索的。当然保证日志集群的可靠性，zookeeper就得上场了，zookeeper已经是做分布式系统不可避免的技术了。
第三个是统一配置系统，系统的配置一般是指将一些环境的参数，系统的参数或者是某些会经常变化的信息用一种特殊的文件保存起来，这样利于系统的维护和扩展，java里通常使用xml文件和properties文件存储配置信息，而那些会经常改变的信息通常会使用properties文件保存，这种配置管理方式对于规模不大或者变更很少的系统而言十分有效，但是对于互联网公司的大型系统以及一些关联度很高的系统而言，当系统运维到一定程度，配置文件可能是最让人沮丧和痛苦的事情，特别是维护它们的方式是通过人力的方法，其潜在的风险也是非常之大的。以前我有篇文章写道zookeeper一个重要特性就是配置管理，该公司实现的统一配置系统就是通过zookeeper来实现的，至于如何使用zookeeper做配置管理，等我研究好了后我在写一篇文章分享下。统一配置系统同样也是可视化的，使用者不用直接到生产机器上修改配置，重启服务器，而是直接在Web管理系统里操作，配错了可以修改，也可以进行回滚，我们公司这方面和他们真是有差距，我们要改一个配置需要好几个领导审批，然后兴师动众的到机房上线，时常还会出现配置改错改掉的问题。
最后是部署系统，生产部署是一个项目的最后一步，也是心里压力最大、风险最高的一步，如果最后上线部署失败了，这种感受就犹如进行了一次辛苦的长跑，眼看就要到达终点了，没想被一块大石头绊倒了，甚至还会掉到坑里，最后还要挨领导批，那滋味可不好受。我们公司系统部署的问题很多，我们公司的环境可以分为五类：办公环境、开发环境、测试环境、预发布环境和生产环境，办公环境、开发环境和测试环境是通的，这个比较好，但是办公环境、开发环境和测试环境同预发布环境同生产环境基本上是完全隔离的，而且不同环境之间的环境配置，系统配置等等东西都存在或多或少的差异，经常发生，测试环境运行好好的程序到了预发布环境就出现问题，更揪心的是，测试环境和预发布环境都没问题，上了生产出问题了，而且是环境造成，这就让我们每一次部署操作都是小心翼翼的，部署后任然还要投入大量的人力和时间进行监控和测试。与我们交流的公司这边的环境其实比我们这里还要复杂，它们甚至在预发布环境和生产环境之间还有一个仿真的环境，仿真的环境是可以直接从生产上摘取一个服务器，部署新开发的程序，让相关人员进行测试验证，而且部署环境的切换也是有专门的Web系统进行管理，不同环境之间可以做到平滑的过渡。这样部署操作不仅是安全性以及在效率上都有很大的提升。
与我们交流的公司说他们几千名的开发人员只需要20几个运维人员，而我们几十人的开发部就超过了20几个运维人员，的确差距很大，不过这种差距也可以理解的，因为人家有强大的开发团队可以支撑这些内部管理系统的研发，而我们的开发团队人力是严重不足，但我相信只要公司业务蒸蒸日上，这些事情迟早会做的。
由此可以看到互联网的技术远比传统的企业软件复杂的多，互联网的技术基本都是分布式的，因此线程、进程、通讯、分布式技术以及分布式的可靠性是十分的重要。我上面描述的这四种系统，也不是和我们交流的公司自创的，也是大量借鉴与美国牛叉的大型互联网公司，例如facebook，谷歌等等，不知道哪里可以获得这样的资料，有人知道可以给我推荐下，我真想好好研究下，因为这种系统实现的难度还是非常高的，要是能掌握能充分体现程序员的个人价值。