IT民工谈IT管理和AD设计-4

简单是美，成本和效率导致了统一集中扁平化

终于、马上说到AD了。作为企业的IT管理员，面对有成百上千甚至上万的PC、用户，如何提供比较好的支持服务是个很有挑战的事情。我们ITpro和搞开发的developer不一样，系统网络都是成熟的产品，把这些产品看成一个个积木，我们要做的就是选择合适的，组合搭建起符合需要的“小城堡”，或者其他什么东西；也许和开发人员一样，他们只是在另外一个层面，比如选择什么样的中间件、组件、接口、方法？不得不说，开发人员还是更加接近IT的本质，较具体深刻的理解软件这个东西，创造潜力要高于IT pro，至少他们可以从无到有的创建出产品，而我们得基于成熟的产品。要真正理解产品的内在本质和原理，就得费工夫了，厂商的设计文档并不那么透明和容易获得，当然，作为一个复杂的产品，普通的开发人员一般也难以知道他产品这个大象的那个部位，对产品的整体理解很可能还不如经验丰富的产品部署人员，IT pro们了。了解产品的本质、内在的原理很重要，这个需要经验的积累，是我们做系统架构、设计、部署的基础和前提。AD这个产品在统一集中管理windows PC和使用PC的用户账户这块是当前最适合的，对于windows平台来讲，而且没有之一。集中统一是AD这个产品的管理思想，集中统一是化繁为简，比较有效率，节省成本的管理方式。我是这么认为的。比如前段时间，老家的田地被政府重新整理了一遍，每一户的田地基本上都集中到一块，修建了笔直宽敞的主干道，像脉经一样铺开和延伸到整个农场，农民可以直接可以将打好的稻谷放到路边，被机动车拖走，甚至在某些地方，国家将农户的居所都集中在一块。城市的出现和扩大也是一种集中和统一，尽管北京的房价平均达到3万块每平方米，我们的北漂的队伍还在壮大，因为这里充满了机遇，虽然拥堵但是有公交、地铁，对搞IT来看，还得在北京这几个超级城市，趋利避害是人的本能，资源集中到应该是人类发展的低成本选择。冥冥之间好像有些关联，说得有点大，回到我理解的AD，也是体现这集中统一管理思想的产品。它的本质是一个数据库，将记录在里面IT资源编了一个目录，登记的IT资源主要是用户账户和计算机账户，为了管理这些账户，又加上了组策略，为了适应大公司多办公点的情况，加上了站点，为了效率和数据安全，允许部署多个AD服务器，于是又加上了数据同步机制……牢牢地将所有账户统一集中的管理起来。简而言之，AD就是管理计算机和用户账户的数据库。那么AD的设计就是数据库的设计。
关于AD是数据库的理解，AD是一种基于LDAP数据库，当你打开“Active Directory用户和计算机”控制台，会发现里面包含了很多类型的对象，用户账户、计算机账户、安全组、通讯组、OU，当然还有其他什么，不过基本可以忽略，每个对象都有不同的属性，不同的属性也许成就其不一样吧，其中OU这个对象比较特殊，其他的对象可以在它放里面，包括其他OU。多打几个比方来理解AD这个数据库，比方1，把AD看成是一颗树，OU就是枝干，枝干上的叶子就是其他对象，颜色正绿的是用户账户，颜色偏黄的计算机账户，每片叶子都长在树干或者枝干上；比方2，AD是一个大公司，他的组织结构--那些大大小小、父父子子的部门就是不同级别的OU，员工就是员工账户，计算机就是计算机账户，打印机就是打印机对象；LADP数据库就是这么一个树状的结构，通过这种结构将这些对象管理起来，OU在里面起到了枝干的作用，所以AD数据库的部署设计，核心是OU的设计。很多公司也是这么根据组织结构设计了自己AD的OU，每个OU对应显示里面的大大小小部门，然后将员工对应的员工账户和员工使用的计算机对应的计算机账户放在部门OU中。当有新员工入职，IT提前为他创建好账户，准备好计算机，加入到域，用户账户和计算机账户都拖放到对应的OU；当员工调换部门，将计算机和账户也拖放到对应的OU；当公司规模小的时候，这样做还是非常不错的。但是在大一些的公司，基于组织结构的AD的设计将会出现维护的困难。极端的例子有，今天大老板说我们下个月重新调整组织结构，AD管理是否马上苦逼了，要调整OU，移动账户，重新调整很多基于OU的组策略。关于组策略，能不上的就不上，能不基于OU的就不要基于OU，后面你会发现基于OU是多么麻烦。
作为IT民工这么多年有些很离散的感悟：我是倾向于极简主义，对于IT PRO这个我觉得很重要，简单的才有可能更可靠和稳定。另外我也认为机器比人靠谱，能自动化的就自动化了吧。管理上是倾向于分权不如集中，之前也提到过集中统一管理是低成本的选择，层级的管理不如扁平化，职责上能分清楚最好分清楚，否则多层次、职责不清楚导致的沟通成本、互相扯皮等会让人苦不堪言，做事效率会急剧下降。当然，所有的这些都是在一个系统范围内，系统内要力求简单、自动、集中、扁平、子模块之间功能和接口清晰，在这个系统范围之外，那是另外的系统范围，每个系统范围之间也可以追求系统之间的功能和接口之间的清晰，达到广大的高层次的简单。而且，当系统范围内某个功能发现具有潜力发展会另外一个东西时，可以考虑尽快的将它剥离成为一个独立的系统，新的系统和原系统、以及其他系统之间可以保持一种松散耦合式的联系。这样的好处是，系统内部结构简单，子功能清晰，系统之间功能也清晰，互相之间的沟通渠道规范，某个系统即便歇菜了，不会影响过大，每个系统就是个模块，可以被替换和升级，只要他对外的接口是规范的就行。
在V工地高峰的时候，全国一二级大大小小的城市，分布了近四十个工场，大的工场近千人，晓得也有百十来号人，内部的后台和测试用的服务器赶得上一个较大的互联网公司了。去年一直在调整结构，而我们的OU结构基本上没有任何调整和变化，不论是业务缩减还是业务扩展，可以预见的近三年，应该也不用在这方面费精力。原因很简单，我们的AD设计中关于OU结构这块完全抛弃了和公司组织结构的关联，但是仍然可以很方便的展现组织结构以及其他需要的信息。当然，我们仍然对最初用手工、后来W同学提升为用脚本、规范了人事及业务部门邮件发来的入职信息格式，没日没夜创建大量新入职员工的账号的痛苦情景。很明显，如此规模的AD，在账户创建方面能过自动化的管理是解脱苦逼的IT Pro们的最好方法，脚本这个工具也力有不逮了，我记得为了避免创建重复账户，脚本在遍历比较已有账号就会花去数分钟，我们需要一个更快的系统，得益于前公司的经验，H同学很早构想了一个叫A系统的雏形，它将在HR的员工系统和AD系统之间，将员工和用户账户建立对应，将部门和OU建立对应，自动化的完成用户账户、OU等对象的管理。不久就我接手了，在实际问题、与开发团队磨合之中，产品逐渐具体，慢慢成形，发生了一些有意思的变化。为了保障HR的员工信息和AD的员工账户信息一致，我们经历了漫长的数据对比，以数次上线被迫终止，因为数据不一致，初始化失败，我深刻的体会到员工人工管理账户是多么的不靠谱，比如账户乱用，同名之间尤其严重，彼王伟用着此王伟的账户，在职的某某用的是离职的员工某某的账户。。。这就是为什么机器比人靠谱。这就像人类的语言和程序语言，程序语言经过人为的设计有统一的规则，更加正式明确，由此程序编写的系统也是更加正式明确。所有，重复的固化的让机器去做吧，它会做的更好。我们要做的更有价值的是尽量将现实中的东西量化、固化、程序化，压榨机器的每一分每一秒。
继续说有意思的变化，我们去掉OU和部门之间的对应关系，直接的动力是因为我们懒，因为H的退出，实现该功能的没有了实际的经验，开发和我讨论的过程中，觉得实现此功能实在太麻烦。终于在一次HR员工信息和AD账户的一致性对比中，我们认为需要的部门信息，其实员工账户中有，于是我们很快就决定减轻开发的难度，认为这个改变非常好，所以懒人促进了技术的进步，简化了系统，这个系统的简化是非常的重要，其实我们后来并不想它仅仅成为HR和AD之间的一个通道，它需要承担更重要的职责，未来的A系统，成为了公司内部所有应用系统的账户的管理平台，承担如此重要的功能，当然是越简单就越稳定。这其实包含了我们未来希望内部的系统都是用单一的账户来登录，是实现SSO的一个重要基石，所有的员工将会在入职的时候获得一个账户，你可以用这个账户登录工作用计算机，也可以登录文件、邮件系统，也可以登录公司的ERP和其他业务系统，所有的权限都将基于此账户，当然权限管理会是另外一个系统，还会很多系统会从A系统中获取到需要的账户信息，比如员工的汇报关系、办公地点、联系方式等等。我欣赏这种松散耦合式的结构。从AD这边来看，更重要的是，我对AD是数据库的本质理解开始变得更加深刻起来。为了适应这种变化，我们不得不重新设计AD的OU，OU被彻底扁平化了，OU的层级甚至没有！同一类型的对象被划分到同一个OU下，这个是我们OU的设计原则，所以对象的分类是关键。我们是这样对AD的对象进行分类的：服务器计算机账户、客户端计算机账户、员工用户账户、安全组、通讯组，这些对象就对应了一级OU，下面不在有子OU，所有的数万的员工账户被扔进了一个和员工用户账户对应的一级OU容器中。这样的设计是很需要勇气的，正式实施前，我们了解到周围微软IT PRO圈子里面的都没有过。但是对开发A系统的工程师来讲，他会很简单去写程序，不用判断到底放哪，直接往特定的一个里面扔。不过以上只是为了描述简单，其实还是有子OU的，比如服务器计算机账户对应的一级OU下，我们根据地理位置创建了二级OU，这个有没有必要不是很好说，我希望你可以看得到这种AD的设计思想，这种分类的思想，关于分类，我认为能够分的就分，分不清楚的干脆就别分，我们的一二级OU的分类就体系了这种思想。以技术或者物理为特点的分类是最好的，比如男人和女人（人妖这个我比较无语），南方和北方，北京和上海，计算机账户和用户账户，服务器和办公PC，这些特点鲜明的随着时间推移也不怎么会有歧义的可以称之为强分类，经常随着时间或者其他什么情况变化的分类最好小心采用（比如员工和领导、同事和朋友和敌人、公司的组织结构），尤其在一些类似OU这种数据结构中，其他的很多方面可以参考。OU被我们固化了，随之的基于OU的组策略也必定淡化，所以，我们的组策略多是采用站点筛选、安全组筛选、WMI筛选来应用，最好，除非必要就不要上，简单是美。