在一个领域内工作了4年，整理了一下自己这些年在运维领域逐步积累起的知识体系。

1.概述

设计并发开一套远程管理系统，由单点触发管理所有的内部机器，兼容Windows与Linux，可以方便化的开发并增加模块，并且便于部署与版本更新升级。

2.实现目标和意义

1. 作为系统部对机器进行远程管理的中间件
2. 实现运维人员可以在从单点触发管理目前线上的机器（Windows/Linux）
3. 使开发人员可以方便的接入远程管理系统，并通过远程管理接口操作线上机器，实现运维自动化
4. 实现机器的定时任务集中管理

最近社区老被刷，可能是网上曝出的库太多，由很多人去尝试来撞库，粗略统计一下，整个刷的请求量竟然占到了社区整体请求量的60-%-70%,这当然不能忍，最近正在研究Storm，经过一个周末的开发与部署，目前基于Storm的CC防火墙已经应用于社区，目前CC防火墙的限制还是比较低的，但是也有效的将刷的比例降低到了5%一下，下面来看一下技术上的设计。

当前我们社区的架构采用的是在全国各个机房搭建Squid进行静态资源缓存，动态请求透过Squid到后台的几个Nginx，由Nginx转发到后端的IIS与Tomcat，整体的社区一天动态PV在亿级别以上。

目前的防火墙支持动态设置每访问x次的y秒数，低于y秒数时就会对IP进行封锁，支持IP白名单与URL黑名单功能。

从接手团队开始就一直在致力于打造高效，高质量的开发团队，历经千辛万苦，团队从一无所有到现在的组织结构，项目管理结构到业务的全面梳理，回想整个过程也是非常的有成就感，项目管理的制定到落地实施2个月的时间，组织结果的变化历经4个月的时间，到我们现在每日的工作汇总表的公布，每周的项目进度报告会，并且依据整体的管理思想建设而成的Wiki，其实从整个Wiki上就可以看出当前的部门管理的方法轮，下面就抛砖引玉公开一下目录结构吧。

规范

应用开发管理架构

• 部门组织架构
• 项目组织架构
• 文档管理体系

项目管理规范

• 常规开发指导规范
• 敏捷开发指导规范
• 项目管理概论：PMI项目管理、Scrum敏捷开发
  阅读全文 »

今年上半年的一个重点项目就是全面升级我们的内部ITSM管理系统，在我们部门内部的名称为中心应用。阐述一下整体的设计思路吧。在整个的管理系统内，将分为资产与业务两大业务板块，两大板块中的关联会在业务内的应用上与资产内的实体机/虚拟机/云主机进行关联，所有的子集实体均集成父级实体的所有属性。

在资产中，整体层级为3级，我们将自有机房与云主机作为一级的大类，自有机房下分机柜-》实体机/交换机-》虚拟机，云主机下分-》机房-》云主机

在业务中，同样为三级，即大类，小类，应用，因业务与公司有关所以不详细说了，但是预计游戏发行公司的业务范围应大致相同，可进行参考。

下面是思维导图：

去年10月份接手WEB运维后一直在致力于WEB运维自动化的各项组件的设计与开发，如上面提到的基于Thrift的远程管理系统，下面来看一下WEB运维自动化的基础库实现。
基础库实现的业务包含：

• 异地容灾：实现切换业务的线上IDC ID自动化切换业务的生产IDC
• 业务监控：各节点及版本库与中心库一致性监控
• 业务一键创建：创建DB，创建WEB（自动Squid,Nginx配置）
  阅读全文 »

经过几个月的规划的施工，目前WEB自动化运维系统已经初见规模了，当然虽然是Web自动化运维系统，但究其根本还是一套远程管理系统，因为目前业务主要管理的是windows机器，所以整个系统使用C#来进行的编写，但也是有部分业务是跑在Linux下的，后续还会增加Linux的支持，虽然已经到内部的3.0版本，但目前项目还在初期阶段，整体的架构还存在很大的完善空间，目前项目还没有进行开源化，待管理界面确定后将会对其进行开源。

前言

又是一年，写个人总结一年比一年懈怠，但是这个总结是不能丢的，写到今年已经是第六年了，回顾今年一年收获颇多，但主要的收获是在工作上，今年几乎把所有的经历都投入了工作，基本上没有关系其他的事情，但是有投入就有回报与成长，今年还是与往常一样，来重新分析一下一年的得失，最后完成对16年的畅想。

最近忙着很多的技术，管理类工作，Blog好久没有更新了，近期我对团队内部的项目管理模式进行了革新，融合项目管理知识体系的部分内容，并根据符合目前团队敏捷管理建立了一套新的项目管理工具，旨在解决目前项目的质量，进度，沟通的问题。在新版的项目管理体系中，标准的项目管理知识体系中的生命周期，5大过程组，10大知识领域都有进行取舍的融入点，且敏捷的各类执行会议等也都进行了良好的融合，在不花费高成本的管理代价下，以敏捷的形式进行项目管理，这个有机会在后期跟大家分析。

最近在我们的一次组织交流会上分享了项目管理知识体系中关于沟通管理与干系人管理的内容PPT，先发来分享一下。

经过半年的系统开发与数据分析，目前最为复杂的地方就是在游戏研发方记录的LOG日志上，每个CP团队的日志记录方式，时间点均有所差异，而面对产品所需要的数据我们只能逐一进行分析，而且尤其是时间点问题导致数据计算异常的事情时有发生，鉴于以上的问题进过多部分游戏的分析最终产出一套基于我们开发的系统的标准LOG库，并且逐步的与新接入研发方沟通，在数据记录/时间点上以此作为规范。
以下的数据基本上囊括了我们的产品所需要计算的所有数值，也几乎容纳了网上对于游戏运营所需要的基础数值。

结构简述

手游日志库包含两部分，
1、 中心数据库(ucenter)，所有的游戏公用的数据库，存储未分区服前的数据，
2、 独立游戏库(ugame)，每区服一个，存储已区分区服的游戏数据