專案報警機制
如何判斷乙個專案正在向這個方向發展（但尚未陷入災難之中）呢？如何在拯救措施的成本變高之前判斷出需要對軟體專案採取一定的措施？這些問題的答案在於
ews系統的報警機制。
出於討論的目的，我們將問題劃分為專案管理相關（例如行政、管理、過程、環境等問題）和產品相關（例如軟體的
bug）兩類。專案和產品問題根據其所處的嚴重程度，分為下面幾類：1．
危急類危急類產品問題：造成產品不可用或者接近不可用的產品缺陷
。危急類專案問題：若不將之克服專案就無法取得成功的、與專案有關的問題。2．
嚴重類嚴重類產品問題：致使乙個主要的產品功能不可用但整個產品尚可使用的產品缺陷。
嚴重類專案問題：如果不及時改正，將導致下面與專案有關的問題：
—極大影響使用者的滿意度。有證據顯示預期會使用或購買產品的使用者中有
20%或者更多將不會使用或購買該產品。
—導致專案的經費預算超支
20%。
—導致專案的時間預算超出
20%。3．
輕微類輕微類產品問題：導致產品難用的缺陷，但產品的其他主要功能仍然能有效執行。該類別中還包括其他不危急也不嚴重的產品缺陷。
輕微類專案問題：指那些既不危急也不嚴重的與專案有關的問題。
危急類和嚴重類問題能夠觸發警報，具體來說，依據危急類和嚴重類問題的數量、清空問題列表所需要的時間以及解決問題的進展情況等屬性，判斷是否觸發警報。例如，在乙個戰略軟體系統或生命支援軟體系統中，只要有乙個危急類問題在專案中存在的時間超過了乙個評審週期，就可能會響起警報。在針對非緊急事務的軟體系統專案中（如乙個考勤管理系統），報警機制可能會較為複雜。
報警機制中經常會考慮到時效因素，也就是說，如果不對危急類和嚴重類問題加以解決，那麼隨著時間的流逝，它們的嚴重性會不斷增加。下面是乙個報警機制示例（括號中是引數值樣例）：
1．對於乙個新出現的危急類問題，賦予它
x點值（例如，5）；
2．對於乙個停留在問題列表裡的危急類問題，每過去乙個匯報週期（例如，
1週為乙個匯報週期），為其增加
y點值（例如，2）；
3．對於乙個新出現的嚴重類問題，賦予它
z點值（例如，1）；
4．對於乙個停留在問題列表裡的嚴重類問題，每過去乙個匯報週期（例如，
1週為乙個匯報週期），為其增加
u點值（例如，1）；
5．將問題列表中所有危急類和嚴重類問題的值相加，計算出總和；
6．如果總和大於報警臨界值
v（例如，
20）那麼，就拉響警報。x、
y、z、
u、v的值取決於專案、開發中的產品、開發機構、產品客戶和使用者、開發機構的歷史（以前的專案中問題解決情況如何）等方面的特徵。有兩條約束x、
y、z、
u、v值的規則：
1．必須在專案重啟前預先設定這些值；
2．在專案開發過程中，對這些值的更改應受到限制，不應頻繁改動。
這兩條規則確保了報警機制不會被輕率地改動。
大體來說，好的專案報**法會以對專案的較全面審視（而不是僅以乙個問題）為報警依據。不過，當乙個問題具有壓倒性的影響（即由於該問題，專案失敗的可能性很明顯）時，警報也可能會被拉響。
我們在前面提到過，如果開發機構已經有乙個有效的
ews，那麼在被拯救的專案重啟時，應使用那個
ews。對於其他機構來說，可以以前面例子中示例的x、
y、z、
u、v值開始，然後在專案推進過程中對這些值進行改進，通過這樣建立起一種簡單但有效的報警機制。不過，需要注意的一點是，不應頻繁地對這些值進行改動（x、
y、z、
u、v規則已對這一點做了規定）。
本文節選自《災難拯救
——讓軟體專案重回軌道》一書[美
]bennatan
（本拿塔）
著侯豔飛，侯玉芳，李萌
譯圖書詳細資訊
:
專案報警機制
專案報警機制 如何判斷乙個專案正在向這個方向發展 但尚未陷入災難之中 呢？如何在拯救措施的成本變高之前判斷出需要對軟體專案採取一定的措施？這些問題的答案在於 ews系統的報警機制。出於討論的目的，我們將問題劃分為專案管理相關 例如行政 管理 過程 環境等問題 和產品相關 例如軟體的 bug 兩類。專...
EFK sentinl報警機制
架構系列文章 efk的部署可以參考 efk缺少乙個報警機制 下面我們嘗試幾種方法來設定報警 先構建映象，dockerfile檔案內容如下 在當前資料夾執行 sudo docker build t luanpeng lp kibana oss 6.2.4 安裝外掛程式 run yum install ...
aiCache 自動監測和報警機制
雖然通過cli,snmp和web埠,aicache都可以監測和解決問題,並提供一系列豐富的統計資料和測試報告,但我們認使用snmp作為製表,報告和歷史記錄的分析 如果您的軟體支援的話 最為理想。aicache提供的自動報警機制可以充分簡化問題,使你為一天的工作做好準備。通過進行設定,我們可以監測許多...