DevOps研習社:品質決定成敗——漫談非功能性需求本期看點

　　
　　本篇文章主要分析了應用的非功能性需求，F5如何幫助應用實現業務邏輯以外的功能。例如：高可用性、安全性、可維護性等等。
　
　　朱傑
　　F5金融事業部技術顧問
　　F5金融事業部技術顧問，專一於應用的用戶體驗，具備豐富的應用交付、UI/UE工做經驗。

　　軟件的非功能需求
　　在互聯網的世界裏，「用戶就是上帝」這句話只體如今支付環節。
　　而在平常生活中，幾乎每個人都清楚的知道，不管是產品仍是服務，品質決定競爭力，而對於一個軟件、應用或者App來講，功能是生命線，肯定可否安身立命，而非功能需求則是它的品質。
　　一個軟件、應用或者App的特性表如今兩個方面，功能性與非功能性。功能性好理解，硬指標，開發過程當中的里程碑，必定要啃下的山頭，而非功能性需求更偏「軟」，如App好很差用，速度快不快，設計是否反人類等。在咱們的平常生活中，非核心、非會員，只要帶了一個「非」字，每每都不是那麼重要的，可不能由於非功能性帶了一個「非」字就常規鄙視它，。在遙遠的古代（10年前），IT市場上的物資（應用）十分匱乏，這個時候，生存是文明的第一須要，可以實現主線功能就有能力去市場上衝衝浪，佔佔山頭，用戶也廣泛具備超高的容忍度和耐心，即便有些許不爽也只能忍受着用着「卡/醜/難」的App；但在App如過江之卿的今天，用戶們翻身奴隸把歌唱，分分鐘能夠卸載掉一個哪怕只有一點點讓本身不爽的App，轉身下載一個同類的，所需的成本不過滑動幾下手指頭。
　　因此，在這個用戶心目中最好的信息時代裏，即便是歷史巨頭如故步自封，也會在一日之間山河破碎，動搖根基，一樣的，哪怕名不見經傳的App，如視用戶爲上帝，想起所難，及其所及，可能會一朝成名天下知。
　　在當下的App爆發式增加，而且同質化嚴重的狀況下，非功能需求這些個「軟服務」會更好的體現出App差別化的特色，向用戶傳遞特定觀點，提供優質服務，從而可以俘獲用戶的「芳心」。
　　說了這麼多，讓咱們來看看非功能需求都包括哪些「軟」指標。下面是ISO/IEC 25010 軟件質量管理模型：
　

　　能夠看到，除了功能性外，影響軟件產品質量的關鍵因素還包括效率、兼容性、易用性、安全性、可靠性、可維護性和可移植性7個維度，每一個維度又包括了許多方面，涉及到架構、內容、交互、運營、安全等，這些都屬於非功能需求的範疇。

　　非功能需求服務化
　　咱們先來看一看非功能需求場景化的一些例子，這些例子只是我我的考慮到的，真實的場景數量會遠遠超出這些：
　
　　乍得一看，其實也沒什麼，無非的各類對開發者嚴厲，對用戶友好的要求，但如果要仔細想想，這些需求怎麼樣去一一實現它，就會以爲比較頭疼了，放在哪裏、哪一個部門、哪一個階段貌似都不能一勞永逸，高枕無憂，由於有的需求須要的是服務器資源，如「支持動態用戶1500以上」，有些需求須要的是開發過程解決，好比「系統支持多種瀏覽器」，還有的需求是須要應用發佈以後，運維團隊來實現，好比「普通修改一天內完成」，再有甚者，須要多種資源，多個團培配合着來，好比「應用熱點/流量熱點分析」等。
　　仔細想一想，這可能也是非功能需求這一塊廣泛作的不如預期的緣由，一個定義在軟件質量模型裏面的屬性，居然要指揮架構、運維甚至運營部們協做工做，能夠想象其中的難度。
　　能夠預見，要在非功能需求這塊下功夫，甚至要打穿部門之間的壁壘，讓不一樣的部門同時參與，互相協做，這是一個也過往徹底不一樣的文化氛圍，這不禁讓咱們想到了DevOps這個煊赫一時的名詞，這算不算是異曲同工呢？
　　

　　弄清了須要參與哪些人和部門後，咱們再進一步來剖析具體的非功能需求應該放在軟件生命週期的哪一個階段，亦或是以哪一種形式存在：
　　效率
　　效率，關注點是業務量與資源容量的佔比，以及業務流量的合理分配，對這一塊提出的要求是宜儘可能貼近適應實際的生產需求，而且具有應對業務量的變化（快速增加或者降低）的能力，不宜資源閒置浪費或由於資源調度的不靈活形成的生產影響，這兩點開起來彷佛有些矛盾，不過那是放在姿態的資源分配上，若是採用動態的資源分配方法，那麼就像三維看二維同樣，是有合理的解決途徑的。關於效率的需求在開發和運維過程當中都存在，而且是一個動態的需求；
　　兼容性
　　兼容性，軟件之間是否可以正確地交互和共享信息。兼容性對於軟件的意義取決於開發小組用什麼來定義，以及軟件運行的系統要求的兼容性級別。兼容性包括向後和向前兼容：向後兼容是指可使用軟件的之前版本。向前兼容是指可使用軟件的將來版本。在特定的時間內，可能存在多個版本同時存在的狀況，並所以誕生出新的用戶需求，如易用性需求，通俗來講就是用戶體驗；
　　易用性
　　易用性，是非功能需求裏面最火的一個話題，也是最能體現軟件是否按「用戶就是上帝」的態度來設計的評判標準之一，易用性是與一組規定或者潛在的用戶爲使用其軟件所需作的努力和對這樣的使用所做的評價有關的一組屬性。具體包括：易理解性、易學習性、易操做性等。這類非功能需求是與UI/UE設計有着直接關係的，也就是說這類屬性會關聯到具體的技術性功能需求，也所以，UE究竟是劃分在功能性需求仍是非功能性需求上，尚有一些爭議，可是主流觀點都認爲，這是非功能性需求的一個典型部分；
　　安全性
　　安全性，包括傳輸加密，存儲加密，可破解性，以及各類未被受權的用戶行爲如何防範和控制等，這裏的安全不單針對外部普通用戶，也針對內部不一樣級別的權限用戶的的控制，不單指服務端，也包括傳輸通道，客戶端，細到精巧的技術滲透如慢速撞庫，粗到混合流量的DDoS攻擊，都須要考慮在內，在生活中咱們作任何事情都須要安全感，在信息世界中這種須要更被放大了許多。在安全性的考慮上，須要綜合考慮架構層、網絡層和應用層的安全，還有一個很是重要的因素就是安全的ROI,這裏不僅僅指投入的金錢，更指投入的資源，由於，每每安全性和易用性多是成反比的，因此，靈活適用是安全的一個重要前提；
　　可靠性
　　可靠性，在規定的一段時間和條件下軟件維持其性能水平的能力有關的一組屬性。具體包括：
　　成熟性
　　與有軟件故障引發失效的頻度有關的軟件屬性。
　　容錯性
　　與在軟件故障或違反指定接口的狀況下維持規定的性能水平的能力有關的軟件屬性。如離線錄入支持等。
　　易恢復性
　　與在是小發生後重建其性能水平並恢復直接受影響數據的能力，以及爲達到此目的所需時間和努力有關的軟件屬性。如表單數據自動保存等。
　　這類非功能需求一般是全局的，他除了與系統運行環境、平臺選擇、代碼質量相關以外，還會涉及部分技術性功能需求，他別是容錯性、易恢復性的實現都須要一些具體的功能來支持；
　　可維護性
　　可維護性，維護性是指與進行指定的修改所需的努力有關的一組屬性。具體包括：
　　易分析性
　　與爲診斷缺陷或者失效緣由及爲斷定待修改的部分所需努力有關的軟件屬性。如日誌記錄系統等。
　　易改變性
　　與進行修改排除錯誤或者適應環境變化所需努力有關的軟件屬性。
　　穩定性
　　與修改所形成的未預料結果的風險有關的軟件屬性。
　　易測試性
　　與確認已修改軟件所需的努力有關的軟件屬性。

　　這部分一般是開發團隊最容易投入時間和成本的地方，諸如動態屬性支持、UI界面生成、流程引擎等都是爲了提升系統的可維護性，所以它顯然是會引伸出相關的技術性功能需求的。更進一步的時，在應用發佈的運維和運營工做中，對可維護性的需求也是愈來愈來，所以，一些須要頻繁變化或者作安全隔離的非功能需求的實現能夠從軟件開發包裏單拉出來，造成單獨的服務交付層，用來實現更多的對可維護性要求高的目標；
　　可移植性
　　可移植性，簡單來講是軟件是否具有在不一樣的環境中轉移的能力，具體包括：
　　適應性
　　與軟件無需採用有別於爲該軟件準備的活動和手段就可能適應不一樣的規定環境有關的軟件屬性。如全球技術支持等。

　　易安裝性
　　與在指定的環境下安裝軟件所需努力有關的軟件屬性。如在線更新、安裝包自動生成等。

　　遵循性
　　使軟件遵循與可移植性有關的標準或約定的軟件屬性。

　　易替換性
　　與軟件在該環境中用來替代指定的其餘軟件的機會和努力有關的軟件屬性。

　　這部分除了須要經過選擇正確的開發工具、平臺來支持外，也會涉及一些技巧性的功能需求，如全球語言支持等。
　　好了，上述咱們分析了這麼多，咱們發現非功能需求的有一些共同點：
　　1
　　當不只存在於開發階段，還存在於運維階段與運營階段；
　　2
　　在實現自身需求的同事，會涉及或者引起新的需求；
　　3
　　對實現手段的靈活程度和後續的管理與維護的便捷度有要求。
　　基於以上三個特色，咱們發現基於非功能性需求的實現不管是單單放在開發階段，仍是隻放在運維階段，都是不完美的，所以，咱們大膽假設，獨立設計一個應用服務層，用戶實現非功能需求的場景，而且貫穿與開發與運維的生命週期內。
　　非功能需求在運維工做中的體現
　　在平常的運維工做中，咱們常常面對非功能需求的目標場景，只是也許咱們意識不到，大到多活中心應用發佈與運維，跨雲中心應用發佈與運維，DNS智能解析，跨中心Cookie會話保持，小到用戶身份識別與流量˙轉發，長鏈接MBLB的拆分及轉發，Http參數優化又或者是URL重寫，以及增強認證受權管理等，都屬於可靠性、安全性、易用性的範疇，還有更多數不完的實際工做任務均可以歸到肺功能需求這一塊，爲何原來僅僅是在軟件質量模型裏的需求如今已經延伸到了運維工做中，是由於開發與運維的界限慢慢模糊化了，對應用品質的追求的過程當中人們也慢慢找到了規律，積攢了經驗。而在運維工做裏，咱們早就已經有了一個概念，叫作應用交付層，這一層可以提供計算、分流、安全、卸載等功能，而且可以無視數據中心數量與形態的變化，與應用緊密結合在一塊兒，旨在爲用戶提供高品質的應用和服務。
　　

　　可是，目前來講這部分的工做仍是存在着明顯的不足，由於這些僅僅仍是屬於運維部門的工做，並且效率也遠遠談不上高效，一般都是以在固定的工程時間窗口裏完成有限的變動這種手段來完成，而對於應用的不瞭解致使能完成的工做也極其有限，這種方式讓咱們看到了企業追求卓越品質的意願，可是與實際上用戶與市場的需求想去甚遠。
　　針對運維工做中提供非功能需求實現與維護的場景，咱們爲了彌補環境多樣化、效率低、需求不明確等諸多不足，應該作到如下幾點：
　　01
　　構建跨平臺的應用服務交付層，建設一致交付的能力，知足可靠性的要求；
　　02
　　應用服務交付層應具有優秀的應用交付服務能力，知足效率的要求；
　　03
　　實現應用的部分非功能性需求解耦，知足易用性與可維護性的要求。
　　完成了上面三點，還不夠，前文已經提到，非功能性需求不是在一個環節、一個階段內可以完美搞定的，因此，咱們要打通渠道開發的那條線，想要打通開發那條線，不是說說就能夠了的，必須具有開發的一些「屬性」：
　　01
　　要可以實現服務交付即代碼，及全部運維平面的工做，可以經過代碼來實現；
　　02
　　要可以與運維平面的服務等級與能力保持一致性；
　　03
　　實現的非功能需求的服務能力要是安全的，可控的；
　　04
　　全部開發測代碼實現的非功能需求，能夠無縫轉化爲服務交付層的服務能力。

　　非功能需求在開發工做中的體現
　　前面談了運維工做中的非功能需求的實現，以及如何與開發工做中的肺功能需求結合，那麼下面咱們來談談在開發工做中如何較好的實現和管理非功能需求場景。
　　我見過很多的互聯網應用，在自己的代碼層裏已經寫入了一些非功能需求的實現，可是可謂是慘不忍睹，稍好一些的一個例子是，在前端頁面用JS來監聽事件，判斷用戶的行爲，來作一些安全的審查和表格填寫的審計，好比，用戶輸入了相似注入攻擊的字段，又或者是有些輸入沒有輸入必需要填的信息等，這樣的實現手段落後不說，實際上還存在多重風險：
　　1若是在業務發佈的時候有通過WAF，那麼這裏的代碼實際上就重複了，不但沒有提升應用的品質，反而下降了效率；2較多的js事件監聽，會形成潛在的安全風險；3不能適應敏捷的變動，若是涉及到這裏寫死了的策略須要更改，就須要改應用。
　　除了上述的例子，還有數不清的相似的狀況，由於開發人員關心的是主線功能的設計與實現，而如今的敏捷開發更是引入了Sprint的概念，時間分秒必爭，到了非功能需求的實現的時候就可能會出現敷衍瞭解，亦或者鎖邊從一些公共的或者缺少有效管理的庫或者源拉一個就用，這樣不管是對效率、安全、以及維護的便捷性來講都不是一個好的辦法。
　　那麼，按照在運維側的思路，咱們是否也能夠爲咱們的應用獨立設計一個服務交付層，將非功能性的需求實現放在這裏，而這些需求能夠採用更專業的實現的同時，同時也隔離了一些公共代碼和庫的安全問題，更妙的由於代碼實現的場景可以無縫的部署在運維側，因此可以和運維打通，互通有無，能作更多的事情，提高應用的品質。
　　

　　如上圖，咱們能夠在代碼code階段就設計爲App code 和ADC Code，而後再build階段先集成App的code，而後作測試，在Deploy階段的時候由CI Server從github上拉取ADC的code，而後一塊兒部署App和ADC Service到服務器或者容器平臺，ADC的code部門還能夠再細分紅ADC code 和Security Code，後者用來作應用層的安全防禦，在這樣的情境下，在每一次code的階段就設計好ADC 和Security的實現，和App Code 同時Deploy，實現了總體應用和安全交付的CI/CD和快速迭代，極大的提升了生產和運維效率。
　　若是想實現開發側的應用交付層的設計，須要具有如下的能力：
　　1要可以實現獨立的服務交付層，與應用核心代碼解耦；2要夠無縫的集成CI/CD；3實現的功能無開發語言無關爲佳。

　　DevOps提高App品質
　　前文提到，軟件的非功能需求決定了軟件的品質，在某些程度上與DevOps是不謀而合的。在DevOps的文化裏，不牢牢的打通了運維與開發的屏障，更是將各個階段造成了一個生生不息的循環，造成一個持續集成、持續交付的生態，若是說DevOps是一種文化，一種氛圍，追求高品質的App是目的，那麼，努力發展非功能需求的實現及優化則是一種行之有效的手段。
　

　　因爲實現了非功能需求的服務化，在一個良好的DevOps的氛圍裏，咱們甚至能夠利用這些服務來作在線BI甚至精準營銷，由運營側提出需求，指定基於App的用戶行爲分析圖，而後分析收集的數據，反向推進優化非功能需求的實現甚至是主線功能需求的優化，從而達到提高客戶滿意度，提高市場佔有率的目的。因爲咱們已經打通了應用交付服務的關節，因此這些數據和分析與每一個部門各自爲戰比起來，要精準、快速、高效的多。