作者：田逸（[email protected]）
按：這是一篇命題作文，是應一位同行兄弟的邀請而作此文。他告訴我，目前他跟開發的關係有些僵持，希望能我能發表一些看法。儘管我不一定能給出好的建議，但我覺得這個事情應該具有一定的普遍性，於是就答應寫一篇文字，權作拋磚引玉。
總所周知，一個網站或者一個項目要創建和運營，絕不是一個人可以完成的（個人玩玩那種不算）。至少需要產品、設計、程序開發（前端、後臺）、測試、系統維護（部署、運營、維護）、平臺運營等等若干職位。
在團隊的認知中，某些職位的人總喜歡強勢認爲自己很重要，是處於主導地位的。於是在這些人的意識裏，其它職位或人員都是輔助和次要的，是圍繞着他的。在這樣的環境裏，造成人員衝突的機率就大，相互協作的意識就幾乎不存在。如果項目最高領導（老闆）也有這種認識，那麼情況就更佳糟糕。
在大部分不規範的或者不是以技術做驅動的公司裏，一個比較典型的情況就是：對於系統運維人員，如果系統長期穩定運行，一些人就會認爲，這些人是不是多餘的？反之，如果故障頻發，一些人有開始抱怨，運維是幹啥的啊，怎麼老出問題？
造成這些問題的原因可能是多方面的，可能是認識問題，也可能是項目本身的問題（比如交易型網站運維的地位就要比宣傳型網站運維的地位高）。對於我們個人來說，我建議找工作的時候，儘量找交易型的，畢竟公司的存在是以系統平臺來賺錢，系統停止就意味着損失，因此個人在組織中的地位自然就比那種宣傳型的網站高了不少。對於認識方面的問題，情況比較複雜，需要做更多的分析和考慮。
回到我們的主題上來。隨便是一個程序員或者測試人員跑過來，就要求幹這幹那。沒有書面文檔，也沒有一個流程。這樣次數多了，運維人員多半就會感覺被支配，不耐煩，疲於應付。第二種情況是：出現故障，先推給運維。這個真的最要命，也最容易起糾紛。想必不少運維同行也有此遭遇。
儘管我很久沒專注於技術，寫這些文字也有些力不從心，勉爲其難拋一些想法，供大夥參考。
◎主動
搞技術的人，性格內向的比較普遍，不知道是不是因爲長時間跟機器打交道的原因。但不能怎樣，主動與人溝通依然是很重要的工作。我們得告訴其它人，運維實際上在幹很多事情（選機房、做系統架構、技術選型、日常維護、半夜爬起來跑機房、24小時響應…此處神略65535字），要說出來，項目列得越詳細越好！有些事情在其它人看來（比如開發人員）似乎很簡單，不就是上架服務器，安裝個系統麼？那麼我們就要跟他較真：哪個機房帶寬質量好？哪個機房服務到位？怎麼裝系統更快、更符合要求（不要給我們講一路回車，一根到底、程序數據一鍋端）？做了要說，而且要多說，才能讓別人瞭解我們其實下了很多功夫，做了很多工作。我時不時會給其它人強調，你們設計的界面在美觀、程序再怎麼牛逼，系統崩潰了，僅僅是一堆佔據硬盤空間的二進制而已！就算沒崩潰，找的機房線路垃圾，能跑的起來纔是怪事呢！
中國人是一個人情社會，只有大家時不時一起吃個飯，很多事情就好商量了。你是否準備請或者被請，跟其它部門的人一起出去吃飯呢？
◎協作
把責任推給別人，原因很簡單—利益和麪子！誰願意努力付出了，最後卻因爲發生故障扣錢甚至影響前途呢（很多機構只注重處罰而很少提及獎勵）？遇到人品差的，這種情況發生得就很頻繁了。
沒有人保證系統運行中不發生問題或故障，除非把電源給關閉掉。我經常的措施是：
（1） 收集相關資源的聯繫方式：機房、供貨商、服務提供商（cdn之類的）；
（2） 收集相關技術人員的聯繫方式：技術負責人、程序員、測試等等；
（3） 根據業務，故障報警發相關人員；
（4） 聯繫接口人員告知故障發生，獲取故障現象並簡單描述
（5） 要求相關人員協調排查；
（6） 告知自己排查的情況（查了哪些項目、數值是什麼狀況、修改了什麼、數據截圖等）；
（7） 故障排除，總結經驗；
（8） 內部討論一下，看能否大事化小（小事化了要看具體情況）。如果不是己方的責任，過分強調過錯或過失，又會回到相互推卸責任這個老路上來。
◎流程
沒有流程，必定會引起一團糟，比如前邊說的，隨便是個人就跑過來提要求；流程太繁瑣，也不行，會嚴重影響效率。在這裏，不強調怎麼做流程，但起碼，我們可以相互約定一個接口人，有什麼需求，儘量通過接口人。
如果、如果什麼都不能改變，儘快閃人吧！
2015-2-21 於大興出租屋