第一篇：運維服務項目管理心得—質量管理

運維服務項目管理心得—質量管理

2016年11月有幸承接了廣州市花都區某局信息化設備及系統運行維護項目的實施工作，為了保證客戶能得到有質量保障的運維服務，我公司建立了完善的服務制度和擁有專業的運維服務團隊。我公司整合運維服務資源，規范運維行為，確保服務質效，形成統一管理、集約高效的一體化運維服務質量保障體系，從而保障客戶的設備及業務系統能安全、穩定、高效、持續的運行。

在日常運維服務支持過程中，為了有效保障項目的實施質量，我按照IT服務管理的運行服務是“持續不斷提高與改進”的服務原則，按照PDCA循環持續對運維服務的質量進行優化提升。我主要從如下幾個方面來保證項目的服務質量：

首先，制定運維服務操作標準，要求實施團隊嚴格按照公司相關服務標準為客戶提供服務；

其次，我在項目小組中將服務臺兼任運維服務質量監督崗，有服務臺對每次的服務工單進行客戶回訪，了解客戶對我司運維服務的滿意度；

第三，我還邀請公司的質量管理團隊每月對項目實施的服務質量進行監督檢查，然后出具第三方的項目運維服務質量報告；

第四，每月組織質量評審會，邀請公司質量部門、客戶共同參加，會對上月的運維服務質量、客戶滿意度及存在問題進行全面總結，針對項目中碰到的質量問題，會現場討論解決辦法，會后形成解決方案；

第五，提出質量整改方案后，交由客戶和質量部門確認，再由項目組實施，實施完成后由公司質量部門進行重新評估，評估通過后出具整改報告給到客戶、質量部門和公司高層。

通過上述五個方面，有效的保障整個項目的服務質量，在2017年項目驗收時，客戶給予了我們五星服務的評價。

慧翔天地廣州學員黃賢裕

第二篇：IT運維心得分享范文

360公司運維心得分享

在很多“外人”的眼中，運維工程師的工作不過是搬機器、調網絡、裝軟件、處理故障、7×24小時值班，簡單而又枯燥至極。但事實并非如此，運維工作涵蓋很多技術領域，運維工程師要掌握硬件、軟件、操作系統、開發等多方面的知識，核心目標是為億萬用戶使用的產品保駕護航。

當今互聯網行業的發展日新月異，新技術層出不窮。為了適應發展趨勢，運維工程師只有提升技術能力才能更好地完成艱巨的運維任務，必須要對傳統運維發出自我挑戰。

在360，運維團隊由基礎運維團隊、網絡運維團隊和應用運維團隊三部分組成。我們將運維從技術支持領域升級，進行產品化改進，核心目標是為了降低運維成本、縮短研發周期、讓產品試錯更廉價。理想很豐滿，現實很骨感，從最初服務少量項目、幾十臺服務器，發展到大量具有數億用戶的項目，我們也在不斷摸索，在試錯中成長。在這個過程中，我們經歷了兩次重要的升級。第一次升級：運維工具化

運維工作中有很多瑣碎的、重復的事情，初期我們只有兩個IDC，服務器數量有限，項目數量也較少，靠純手工勞作還可以應付。但隨著時間的推移，項目暴增，隨之IDC和服務器的數量也成倍增長，同時360各項目都是小團隊在做，開發風格不同、習慣各異，但極致要求響應速度，如果運維工作按照之前方式進行，很難滿足需求。大勢所趨，我們必須進行工具化升級，將重復的事情自動化。

在工具化過程中，我們秉著低成本、拿來即用的原則，借鑒業界成型的方案，同時將精力用在對開源軟件的研究中，有開源工具就絕不自己憑空創造。初期，我們只圍繞開源軟件做周邊腳本開發，不動核心代碼，在實踐中總結經驗。例如，在最基礎的部署軟件環境中，我們基于YUM搭建了自己的包管理系統，將常用軟件打包，同時根據項目做成模板，這樣無論是初始安裝還是擴容都能在分分鐘完成。配置文件管理利用Puppet完成，服務器批量操控依賴SaltStack。就這樣 我們的運維兵器譜在不斷地豐富。

另外，運維工作離不開監控報警，這是一件讓無數運維人苦不堪言的事情。而會休息才會工作，監控體系必須優化。

我們的監控大概分為系統級、應用級、項目邏輯和用戶體驗四部分。系統級主要監控硬件和網絡等；應用級主要監控常用軟件的健康狀況；項目邏輯監控主要模擬用戶行為探測項目功能點是否運行正常；用戶體驗監控主要聯動博睿和基調等第三方監控一起優化用戶體驗。我們用過的工具很多，開源工具有Nagios、Cacti、Ganglia、Zabbix等，同時自己也開發了一些針對項目場景的監控工具，但萬變不離其宗，都是圍繞上述幾個維度進行監控，然后再進行分級預警和報警。

為了減少報警騷擾，我們分級處理，將報警分為郵件預警、短信報警和瘋狂短信報警。以磁盤空間監控為例：每天下午6點，統計 磁盤使用率超過80%的機器，發出郵件預警，下班前解決；在預警的基礎上，超過85%觸發短信報警；超過90%就要持續報警，避免事故的發生。此外，隨著 服務器數量的增多，硬件故障在所難免，架構設計需要考慮高可用方案，冗余范圍內的服務器故障會以郵件預警的方式發出，避免對運維工程師的騷擾。

有了監控工具和分級機制，還需要有好的制度。為了大部分人可以安心休息，我們每天有專人負責處理常規報警，遇到無法解決的問題才要求他人協助。第二天的負責 人要針對第一天的報警找出根本原因，并盡力解決，因為如果無法根治，困擾將持續發生。所謂線上無小事，實際工作中復雜場景引發的問題數不勝數，所以可以寬 容第一次錯誤，但不能接受同樣問題發生第二次，要不斷地總結和完善。

工具化是運維的必經之路，是向更高層發展的基礎，面對運維這樣復雜的學科，這樣一個極其磨煉人意志的工種，運維工程師需要用聰明的方式解決復雜的問題，節省時間，去做更有意義的事情。

第二次升級：運維產品化

我剛提出運維產品化時，有朋友開玩笑說，你做后端運維吃苦受罪這么多年，看著產品經理吃香的喝辣的，羨慕嫉妒也想轉行做產品吧。也有人說，你是在偷換概念，不就是做自動化運維平臺嘛。其實提出這個概念，一方面是源于有了足夠的工具化積累；另一方面是想換一種思路做運維，培養產品觀，站在用戶的角度思考問題，讓處于后端的運維工程師主動挖掘需求，圍繞運維做更多的探索，提升團隊技術能力，解決海量用戶帶來的問題。有了這個想法，就需要將無形的技術轉變為有形的產品形態，同時要賦予它好的寓意。我們的產品取名為HULK——綠巨人，意在讓小伙伴們借助巨人的肩膀成長，輕點鼠標，運籌帷幄。

想到做這個平臺，源于對實際工作需求的觀察。產品經理有了創新點之后，開發工程師就想以最快的速度上線，但又會很痛苦，因為產品就好比寶塔明珠，塔基需要一 層層地蓋。而開發工程師是與運維工程師合作最緊密的兄弟，“兄弟有難得拔刀相助”，因此我們明確了開發工程師就是運維平臺的用戶，運維工程師在平臺的建設 中扮演了多重角色，是建設者也是使用者，但目標是為用戶解決問題，讓我們的用戶有極致的用戶體驗?；谶@些想法，我們勾畫出了宏偉藍圖，提供一個塔基，第一層提供核心基礎服務，如Web、RDB、NoSQL等；第二層提供通用基礎服務，構造一個完美的平臺，讓開發工程師受益。但勾畫的平臺功 能大而全，需求都是我們替用戶假想的，這樣做的后果就是進展緩慢，但做出的功能沒人用。我們在失敗中反思，意識到需求還得從日常工作中去挖掘，平臺上每個功能模塊都必須解決用戶的痛點?；ヂ摼W精神唯快不破，要圍繞“快”找痛點。早期開發和運維的合作中，更多的是郵件、IM及當面溝通，跨團隊的溝通成本是第 一個痛點。初期平臺建設中，我們從加速流程開始進行摸索，以“需求任務流”為核心，將通用需求規范流程，統一需求提交頁面，同時盡量為用戶提供選項，而不是隨意填寫，盡量減少溝通成本，同時為完全自動化打好基礎。由于完整的自動化流程開發成本比較高，初期我們還“投機取巧”，用戶提交需求以后，只是把格式 化的郵件發送給運維工程師。運維工程師使用半自動化工具干活，完成后再通過平臺任務流告知用戶結果，手工操作的部分是隱藏在平臺后面的，用戶不得而知。就 用這種方式，我們的平臺積累了不少用戶和口碑。之后我們將日常需求分層、分類：主機類包括主機申請、賬號授權、軟件部署等；Web類包括配置文件管理、域名管理等；DB類包括建庫、建表、SQL審核、授權等。再攻克技術難點將一個個需求實現完全自動化，點點鼠標解決問題。

關于需求任務流，還有個小插曲，標準的任務流由提交、審核、駁回/通過組成。但這個流程太死板，例如用戶提交的一個需求，在審核的過程中有待商榷，運維工程師會和開發工程師 溝通，最終達成一致意見即可，而如果按標準流程需要駁回再提交。為了讓用戶少一次操作，我們增加了管理員可編譯功能。有些同事反對這樣做，覺得不符合常 理。不過有時候常理是需要結合實際場景打破的，就為了讓用戶使用更簡單。

近期為了進一步提升項目試錯階段的速度，我們在平臺上推出了一個新功能：“項目孵化器”。以典型的Web業務為例，以往，申請Web Server、賬號、數據庫實例、負載均衡等是提給運維最基本的需求，每一步都是時間成本。使用“項目孵化器”可以最大限度解決這個痛點，只需在平臺上進 行兩個步驟：第一步填寫業務名稱，預估峰值QPS；第二步選用MySQL、MongoDB、Redis等相關數據庫資源。兩步之后，Web Server、數據庫實例等所需資源會瞬間展示在用戶面前，同時包管理、配置文件管理、代碼發布系統、監控系統等配套輔助功能隨之開通。

與之前的模式相比，效率和規范化都有明顯提高。說起來很神奇，但實現理念很簡單，我們提煉日常項目中的通用方案，構建資源池，在項目發展初期最小量匹配資源。在孵化器的設計階段，我們聽到了很多不同的聲音。例如，讓用戶填信息不夠全面，架構太簡單不滿足全部需求，諸如此類問題，讓人頭痛欲裂。經過過往項目 分析及用戶調研，發現項目尚處于試錯階段，快速試錯是首要需求。至于項目發展中衍生出來的需求，可以再用平臺擴展功能去解決。當利用孵化器建立一個試錯項目之后，用戶進入平臺想看見什么？展現形式如何？還能做什么？這些問題隨之而來。

眾所周知，項目中的關聯關系是個復雜的問題，解決不好，就像一盤散沙無法聯動。為了解決此問題，首先我們確定平臺各功能模塊以項目名為主鍵，將項目的域名、負載均衡、Web Server、數據庫、通用基礎服務等相關聯。項目后期各功能模塊的擴容可以借助關聯關系自動化完成。例如增加一臺Web Server，即可自動部署軟件環境，完成相關節點授權、上傳代碼、測試上線。

展現形式上我們借鑒社交網站的實現方案，以“我的項目”為中心，用戶進入平臺以后默認頁展示項目在平臺中用到的各功能模塊信息，例如域名、主機數量、數據庫實例和監控指標等。做到信息清晰可見，操控簡單易用。

在平臺建設中，我們一直遵循兩個準則：第一，把事情由復雜變簡單；第二，給用戶極致的用戶體驗。所謂極致，就是要超出用戶的預期，但只有挖掘用戶潛在的需求，才能做出超出預期的功能。傳統的運維模式，大多是開發工程師提需求，運維工程師滿足需求，運維工程師主動推進的意識不夠。360的文化中有很重要的一點是Ownership，一個項目的成功與失敗，運維工程師是有責任的，因此需要在日常工作中時刻提醒自己“這個項目是我的，為了讓項目變得更好，我們需要主動思考，為開發工程師提供更多的增值服務”。例如一個項目上線前，會默認部署日志收集模塊，收集匯總后進行訪問日志自動化分析，以時間維度展示訪問量走勢，同時輔以IP地址分析模塊展示地域及運營商分布。同時基于訪問日志狀態碼做進一步的頁面分析，然后以日、周、月維度生成一份體檢報告，以及應對方案推送給開發工程師。這些增值服務是超出預期的，拉近了開發工程師和我們的距離，一起去探討、改進，做出更多有利于項目發展的功能。結束語

運維工作在一家公司中至關重要，但傳統的運維模式一定程度上限制了運維工程師的技術發展，更抑制了創新思維，我們需要利用運維“寬泛技術”定位的優勢開拓思路。例如運維工作需要和很多開發團隊合作，協助架構設計，在這個過程中會接觸到很多開發團隊的技術積累，可以把各家之所長進行聚合，將一些基礎服務進行平臺化改造，資源共享。也可以根據項目的需要，主動做技術研究，將基礎服務做成一個個小產品，提供給開發團隊使用，幫助項目縮短研發周期，穩定發展。在當今技術背景下，運維工程師應該在紅海中尋找藍海的思維模式，培養產品觀，由外至內地思考，突破傳統運維的壁壘，開拓創新。

第三篇：ITSM運維服務項目需求書

ITSM運維服務項目需求書

一、寧波市財稅局信息化服務管理系統簡介

寧波市財稅局信息化服務管理系統（以下簡稱IT服務管理系統）是寧波市財稅局提升信息化運維服務管理水平的重要項目。系統共分為監控平臺和流程系統兩大塊，其中監控平臺由OVO基礎架構監控、BAC業務監控和NNM網絡監控等系統組成，流程系統主要是HP Service Manager流程平臺軟件（以下簡稱SM流程平臺）構成。

IT服務管理系統項目一期自2009年12月啟動，借鑒國際先進的運維管理經驗，逐步建立起一套與財稅信息化建設相匹配的制度化、規范化的運維服務管理系統，實現了以下的基本目標：

1、制定了切實可行的IT服務管理制度和規范；

2、建立了統一的IT服務管理支持平臺和高效的、集中統一的監管平臺；

3、奠定了IT服務管理從分散向集中、從無序到有序、從被動到主動轉變的基礎。

IT服務管理系統經過三年多的建設，目前流程系統已經覆蓋寧波市財稅局各部門及所屬各縣（市）財稅局各部門和基層單位、各區財政局信息中心及各區地稅局各部門和基層單位。與此同時，對原有分散的運維管理工作進行了重新整合，切實提高了我市財稅信息化的運維服務水平，為信息系統運維的規范化、制度化奠定了基礎。經過項目建設、運行和優化，系統的核心功能已經基本具備。

二、招標內容

運維服務內容：

1、IT服務管理系統查詢模塊維護優化

投標方應按招標方要求，對綜合查詢模塊進行維護優化，保證綜合查詢模塊的正常使用，并對招標方提出的合理化需求進行功能優化和調研開發。

2、優化完善運維系統流程 1）系統優化完善

投標方需對項目已實施的工作內容進行優化完善，具體如下：

A）監控平臺的調整改進

監控平臺自2010年底部署以來，招標方的組織架構和IT基礎環境都發生了較大的改變，投標方必須針對現有實際情況對整個監控平臺進行調整和優化。B）配置管理優化整合

投標方需對項目已建立的基本配置信息庫完善配置管理流程，充分發揮配置管理的優勢和作用。C）問題流程實施

投標方應按招標方要求，部署推廣IT服務管理系統的問題流程，讓問題流程在全市財稅系統發揮其應有的作用，體現問題流程的效果。

2）系統駐場維護

投標方需派駐3名專業的運維人員負責招標方IT服務管理系統的日常運維工作，具體工作內容如下：

A)投標方需負責操作系統環境和軟件運行方面的維護工作： ? 保證運維軟件平臺的操作系統及其運行環境的正常穩定運作。? 保證運維軟件平臺的正常運作。? 運維軟件BUG修正：

? 軟件固有BUG，采用官方補丁等手段修正。

? 設計流程等修改操作產生的軟件BUG，分析研究修正。

B)投標方需負責SM流程平臺管理、設計實施和功能修改等工作： ? SM流程平臺系統管理，如用戶權限設定和用戶界面設計等。? SM流程平臺功能修改，改變部分軟件功能。? 錯誤數據修改，對用戶輸入的錯誤數據進行改正。

? 配合完成一些涉及到SM流程平臺的集成開發工作，如提供SM流程平臺的接口等。

? 參與部分流程的具體工作，如事件重分配、變更階段修改等。C)投標方需負責需求訪談、流程推廣和指導培訓等工作：

? 定期進行SM流程平臺的訪談調研工作，聽取招標方用戶的意見和建議，了解用戶對SM流程平臺的感受，為下一步的工作提供參考。

? 需求跟進開發，對用戶提出的問題或解決問題過程中產生的新需求進行研究，征求招標方的意見，進行相應開發工作。

? 流程優化，投標方需適時地根據SM流程平臺運行情況提出優化建議，與招標方討論研究，使SM流程平臺更貼近招標方用戶需求。

? 投標方應按招標方要求對招標方用戶提供現場或非現場的指導服務。? 投標方應按招標方要求對招標方用戶提供定期或不定期的培訓服務。D）投標方需負責系統相關文檔工作： ? 投標方應在每月底提供系統運行報告。

? 投標方需協助招標方完成與SM流程平臺有關的規章制度的建立工作。? 投標方需適時對整個SM流程平臺進行評估，提出可行性方案。

3、全市財稅系統IT服務管理系統運維服務

投標方應按招標方要求，通過SM流程平臺建立全市統一的基于一體化系統的全程技術服務體系，形成責任清晰的問題逐級上報和反饋機制。

投標方應遵循“全市運維問題有記錄，辦理過程有跟蹤，處理結果能反饋”的原則來設計開發縣（市）區運維流程，保證SM流程平臺的高質量、高效率。

如招標方需要，投標方還需完成以下工作：

1）對縣（市）、區單位進行訪談調研，確定流程需求，根據實際情況調整流程。

2）對開發設計好的流程進行電子化實施。

3）對縣（市）、區單位人員進行流程理念宣導和操作培訓等工作。4）對縣（市）、區單位人員的合理咨詢和提問予以答復和改進。

4、Oracle軟件和相關存儲設備的維護

投標方需配備專門的工程師對招標方采購的Oracle GoldenGate軟件和相關存儲設備進行售后維護工作，包括日常使用、故障處理等方面的咨詢答疑、遠程支持、現場支持等工作。

三、其他內容和要求

1）在本項目的執行過程中，投標方需提供固定數量的經招標方認可的工程師全職服務。未經招標方許可，此部分人員工作時間內不得參與本合同以外的其它工作。

2）在本項目的執行過程中，投標方的工作人員必須遵守招標方相關的規章制度，遵守保密協議，與招標方簽訂相關保密協議。投標方須與投標方聘用的此項目的工作人員簽訂保密協議，并交由招標方備案。

3）在本項目的執行過程中，投標方需建立一套經招標方認可的、切實有效的運維機制，并在本項目的執行過程中嚴格按照該運維機制進行系統完善與維護。

4）項目中產生的所有源程序和文檔版權屬招標方所有。服務到期驗收時，投標方需提交項目涉及的所有源程序、設計開發過程中的所有相關文檔。

5)投標方需在投標文件中列出項目所需的

第四篇：IT運維項目管理心得—風險管理

IT運維項目管理心得—風險管理

過在PMP的學習，結合多年的IT運維項目實施管理工作經驗，我對項目管理中的風險管理有了進一步的學習和認識，我真正認識PMP項目管理在現實生活中的運用。

風險管理是預防、規避項目風險的主要手段，是完成項目計劃內的期限、預算內費用、規定的技術指標等的重要保障。在每個風險管理周期都應該做好從設計、合同、進度、質量、費用、溝通等管理工作中收集相關信息，并將這些信息反映在風險管理過程中的各環節工作中，并及時進行反饋。

現將我對項目風險管理的理解總結如下：

1、做好風險識別

在項目啟動階段，將對項目需求及項目實施過程中可能面對的風險進行全面的識別，結合公司已有的風險評估表，對識別出來的風險進行評分。

2、做好風險管控

在項目實施階段，對前期已識別的風險，按照不同的風險等級進行管控，針對高危等級的風險（如：客戶關鍵業務系統宕機）通過外包（購買原廠服務）或采取一定措施降低風險值的方式解決（提供專業人員提供24小時值班監控）；針對中等級的風險，則制定相應的風險解決方案（如：巡檢、定期保養、設備實時監控），來減少或緩解風險的發生概率；針對低等級風險，則采取定期監控方式。

3、做好風險監測

風險監測是持續不間斷進行的過程，主要包含跟蹤已識別的風險，監測殘余風險和識別新的風險，形成風險管理監控報告，對重新識別的風險進行排序形成風險評估表，為管理人員提供決策的量化依據。通過對風險的良好監測和控制并形成風險管理監控報告，在風險發生前做出有效決策，減少風險造成的損失。（慧翔天地廣州學員黃賢裕）

第五篇：信息化設備運維服務項目合同

第一章 合同要求說明

投標人必須響應并承諾以下所附合同主要條款。

合同登記編號：

中國共產黨廣州市委員會辦公廳計算機機房和會議系統設備運維服務項目合同

甲方：中國共產黨廣州市委員會辦公廳 乙方：

甲、乙雙方根據中國共產黨廣州市委員會辦公廳計算機機房和會議系統設備運維服務項目（采購編號：）招標的結果，經雙方友好協商，簽訂下列條款：

一、服務范圍

此次中共廣州市委辦公廳計算機機房和會議系統設備運維服務項目包括辦公廳所屬各個機房的環境設備和會議系統設備兩大部分。其中計算機機房包括辦公廳所屬14個機房及配線間的UPS、精密機房空調設備、以及相關機房及配線間的環境監控設備；會議系統設備分為會議系統設備維護和會議現場支持兩部分。

二、下列文件均為本合同書的組成部分

1、招標文件。

2、供方中標的投標文件。

3、在實施過程中雙方共同簽署的補充文件。

以上文件與合同附件具有同等法律效力，若以上文件與本合同有差異的，以本合同內容為準。

三、服務內容：

對中共廣州市委辦公廳14個機房及配線間（含2號樓2樓會議室機房）的UPS不間斷電源設備、機房空調設備以及相關環境監控設備進行維護；對辦公廳8個會議室（總值班室）的會議系統設備進行檢查、保養和維護，對8個會議室提供會議現場技術支持（2個是視頻會議室）。

四、提供服務的時間和地點

1、提供服務的時間：簽訂合同后起一年內。

2、提供服務的地點：甲方指定地點

五、合同金額

合同總價： 元，（人民幣大寫：）。其中會議系統設備零配件維修所需總費用，采用實報實銷方式，此項費用按維護期內實際發生費用進行結算，維護期結束后將賬務統一移交甲方。

六、款項支付

（一）合同簽訂后15個工作日內，按合同總價的50%辦理支付手續。

（二）運維服務期滿6個月后，中期驗收合格之日起15個工作日內，按合同總價的20%辦理支付手續。

（三）運維服務期滿驗收合格之日起15個工作日內，按合同總價的30%辦理支付手續。

（四）乙方須在甲方辦理付款手續前10個工作日內，提供等額的正式發票給甲方，以便甲方及時辦理付款手續。

七、甲方的權利和義務

1、甲方有權隨時檢查乙方的服務履行情況，并向乙方提出修改。

2、當發生服務違約時，則甲方有權按“服務違約處理標準”在支付乙方工程款項中進行扣款。

3、在乙方提供服務時，如對甲方的設備造成了損壞，甲方有權要求乙方賠償。

4、甲方應按合同規定向乙方支付服務費用。

八、乙方的權利和義務

1、乙方應按招標文件的要求和投標文件的承諾進行服務，發生任何服務的變更均須向甲方提出交書面報審報告。

2、乙方有權要求甲方按時支付服務費用。如甲方不按時支付乙方有權要求甲方支付滯納金。

3、乙方在提供服務時如損壞了甲方的設備，乙方應照價賠償或更換同等設備。若因設備的損壞而引起其它損失的，乙方應作出合理賠償（以甲乙雙方協商或行政仲裁的結果賠償）。

九、保密條款

見附件一 《保密協議》。

十、合同糾紛的解決

在履行合同的過程中，甲、乙雙方如產生合同糾紛，協商不成的情況下，可向合同履行地人民法院提起訴訟。

十一、合同書的有效期間

本合同書一式四份，具有同等法律效力，甲、乙雙方各執一份，廣州公共資源交易中心一份、廣州市財政局一份。合同自雙方簽字的最后一個簽字之日起生效。

十二、約定事項的變更

由于出現不可預見的情況，影響項目工作的如期完成，甲乙雙方可要求變更約定事項，但應及時通知對方，并由雙方協商解決。

十三、本合同書未盡事宜，由甲乙雙方依照《中華人民共和國合同法》協商處理。

十四、簽約地點為：

甲方： 乙方： 地址： 地址： 法定代表人： 法定代表人： 委托代理人： 委托代理人：： 開戶銀行： 開戶銀行： 銀行帳號： 銀行帳號： 項目負責人： 聯系人： 電話：

電話：

簽訂日期：20 年 月 日 簽訂日期：20 年 月 日