簡單是美，成本和效率導致了統一集中扁平化
終於、馬上說到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篩選來應用，最好，除非必要就不要上，簡單是美。