前沿拓展：

tapd登錄

菀的地枋，
鏈接；r-pw.COm?gyre（**粘貼即可打開）
，
，
第一只叫做Dasher，猛沖者的意思
第二只叫做Comet，彗星的意思
第三只叫做Cupid，丘比特
第四只叫做Dancer，跳舞家
第六只叫做Prancer，跳躍
第七只叫做Vixen，雌狐
第八只叫做Donner，是荷蘭語中的雷
第九只叫做Blitzen，也是荷蘭語，閃電
第十只叫做Fireball，火球
第十一只叫做Olive，橄欖
第十二只叫做Rudolph，魯道夫
圣誕老人原本馴鹿的組合只有九只，到了后代才多出了三只，變成了整整十二只。也就是現今我們所知道的圣誕老人馴鹿。
不需要清除刷機恢復的。當在連續輸入鎖屏密碼錯誤5次的時候會提示等待60秒
連續輸入13次錯誤的密碼后出現提示僅有兩次輸入密碼的機會解鎖。
連續錯誤密碼15次后，提示必須輸入魅族Flyme帳號密碼才能進行解鎖。
手機會自動打開手機移動網絡進行在線解鎖。這時只要輸入登錄的flyme賬號的密碼即可。
溫馨提示：輸入正確的魅族Flyme帳號密碼解鎖

在 DevOps 的理念中，企業的 IT 價值鏈流轉的速度越快，意味著企業的互聯網產品的交付能力越強，這也意味著在同行業的競爭中，企業憑借 IT 能力的優勢，能夠收獲更大的競爭優勢。也因此，DevOps 框架的落地與實踐，成為時下非常熱門的話題。

以海量用戶規模和社交網絡業務著稱騰訊公司，在多年前便開始著手的部署 DevOps。在前不久騰訊云 + 未來開發者專場，騰訊云的資深工程師和架構師，通過 DevOps 敏捷開發工具集、DevOps 流水線應用實踐、云端架構與部署、無服務器架構等主題內容介紹，詳細講解了騰訊云海量業務下的 DevOps 架構探索與實踐，InfoQ 將其中精彩內容做了整理，希望給更多人提供參考和借鑒。

騰訊云 DevOps 敏捷開發工具集

一般的軟件產品開發，包含用戶需求分析、架構設計、設計模型、編碼、測試幾個過程。而 DevOps，就是這些過程實現的紐帶，通過開發運營的一體化，可以將軟件開發流程無縫的銜接在一起。

為了順利完成項目的實施，騰訊云開放了 TAPD（騰訊敏捷研發平臺）、TGit（騰訊 Git 源代碼管理）、CCI（持續集成服務）、SODA（游戲持續集成）、織云（云端運維）等 DevOps 系列工具集，通過這些平臺，開發者可快速完成產品的交付與運維。

TAPD 是長期服務于騰訊自有業務的敏捷開發平臺。自 2006 年騰訊推行敏捷開發開始，TAPD 在十年時間內服務了騰訊內部上千團隊的敏捷研發，并梳理出迭代模型、大象模型、極速模型等三種典型研發模型。

TGit 是一款基于 Git 的代碼管理工具。支撐了騰訊各個業務的代碼的編寫和代碼的存儲、積存、部署流程。TGit 支持多客戶端支持，并能提供類 Github 的**作體驗，支持在線代碼檢測與評論等。

CCI 持續集成服務是一款針對 Web 部的前端后臺的數據集成的產品。目前，CCI 可以支持 JAVA，C++、PHP 等語言的構建，并能和 TGit、織云原生兼容。開發者可以將代碼寫在 TGit，又能非常方便的把代碼拉到 CCI 上面去做構建，同時，CCI 還支持定時構建，以及代碼提交時間觸發構建功能。

織云是源自于騰訊的企業級運維管理平臺。亦被稱為一站式新態企業運維平臺，它支持公有云、私有云、混合云管理，能一鍵式運維**作，靈活高效。通過智能構建，織云已能實現無人工值守、多觸發器支持和代碼自動掃描等持續集成功能，整合開發與運維過程。

以上這些產品將陸續開放，感興趣的讀者可以登錄騰訊云官網注冊試用。同時，騰訊云 Devops 產品總監秦俊現場透露，騰訊云將在近期與微信團隊合作推出一個新的功能，該功能依托騰訊云 DevOps 的體系建設，可幫助小程序開發者實現騰訊云帳號的開通、代碼部署、代碼的上傳部署全流程。這項功能將于近期跟隨新版小程序開發工具對開發者免費開放。

騰訊云 DevOps 流水線平臺應用實踐

前面說到了騰訊的 DevOps 工具集，那么，這些工具集在具體的開發流程上都起著怎樣的作用呢？騰訊織云負責人梁定安從騰訊 DevOpsy 應用實踐、應用架構的可運維性以及織云產品的部署實踐三個角度做了詳細的闡述。

騰訊云 DevOps 應用實踐

如圖以下為騰訊云的 DevOps 流水線，開發人員錄入需求，經過 TAPD 項目評審，分解成一個個的直接開發實現的特殊功能，存放在騰訊云內部，進入到持續集成的階段，做自動化的編譯、集成、自動化測試、代碼的近態掃描，如果有一些不合規范的代碼，主干測試無法通過。這時候需要 CIS 解決問題，問題解決以后會形成一個制品庫，和織云系統進行對接，織云系統拿到制品庫，按照騰訊標準的發布、管理的方案，把制品、軟件發布到生產環境，進而去做灰度測試，再上線的一個過程。騰訊的海量業務使用這套流水線系統可以輕松完成從需求設計、代碼管理、開發測試、發布 & 運維的各階段工作。

這其中，TAPD 支持敏捷項目管理，實現產品需求與開發分支關聯；TGit 支持代碼管理，通過 webhook 鉤子觸發持續集成系統的能力；CIS 負責自動化完成編譯、測試等任務，以輸出制品庫：軟件包或 docker 鏡像；織云對接 CIS 獲取制品，以自動化的方式完成業務的發布 / 變更任務。

應用架構的可運維性

對于互聯網產品而言，發布僅僅只是開始，在持續為用戶輸出價值的運營過程，由運維團隊和系統來保障服務的穩定可靠。梁定安認為要實現可運維性的過程可分為 4 個階段：統一架構、運維規范、標準**作、運維自動化。

統一框架：將互聯網的業務架構抽象成為三層：接入層、邏輯層、數據層，框架化的引入，可以有效的降低開發的工作量，通過有限的編碼即可實現快速業務功能需求。

運維規范：組件可以將共性的服務統一化，如騰訊內部大量應用的軟件路由服務，可以幫助實現負載均衡、名字服務、容錯、過載保護、流量調度的功能特性。除了為業務解決了路由的難題，也使日常的運維管理變得更加簡單高效。

標準**作：將工作人員的**作標準化，避免因為崗位人員的流動而導致產品重構，造成重復造車現象的發生。

運維自動化：自動化運維的方案，就是統一規劃、標準化、配置化、自動化、**，這里不能漏了**。

通過雖以上可運維內容的統一規劃與標準化，可以保障了業務架構有序的發展，架構的演變從千人千面進化成千人一面。然后結合框架與組件的非功能規范，使運維保障業務質量與效率的規劃落實。

騰訊云織云的持續部署實踐

隨后，梁定安著重介紹了騰訊云織云平臺的部署實踐。下圖為騰訊織云功能的一覽圖，在織云平臺中，將標準化的運維對象配置化，每個微服務集群在織云 CMDB 中被定義成不同的模塊名。從統一規劃、標準化、配置化、自動化到聯動**，用持續部署的流水線工具串行起來，用戶將得到一個體系化的運維能力模型，基于此模型，運維團隊能夠全局規劃持續部署的能力與工具系統。

以織云的自動化擴容流程為例，將原子運維工具或系統接口以運維的最優**作流程組織起來，自動化的完成擴容**作，并且保證每個步驟都會被嚴格執行到位，不會受個人的經驗深淺或文檔的新舊影響。從而解決運維團隊“文檔即過期，離職即消失”的難題。

云端架構規劃與應用案例

如果說 Devops 是保障產品開發順暢的通行證，那么，云端架構的規劃就是產品順利進行的指南針。一個好的架構規劃，往往能夠使產品在開發的過程中少踩很多“坑”。騰訊云架構師張興華認為，企業在云端架構設計時一般面臨以下幾大架構痛點，并且根據這些痛點提出解決方案：

第一，高可用挑戰。如果產品在架構設計上或者在容災方面考慮不周，將面臨高可用的挑戰。解決方案上可以利用云的資源做多地域的容災，在架構層面可以進行不同層級的拆分，比如講將核心服務和非核心服務進行分級，同時還可以一些做灰度或者迭代的改進。

第二，性能瓶頸。在數據庫的調用過程中，高并發的交互可能會導致數據庫完全無法及時響應。解決方案可以根據需要推出不同的數據庫版本或者針對不同的場景或業務類型，選擇不同的云服務進行不同的優化。

第三，數據庫設計。自建或者自己維護自有的數據庫是比較難的，企業需要提前做好業務上長期規劃，提前做好業務分庫、分表的設計。

第四，安全。目前 DDos 攻擊流量最新數據超過了 600G，抗 DDos 需要借助云服務未雨綢繆；同時在**作、容災、數據、權限等安全層面都需要在架構上提前規劃。

騰訊云架構規劃案例實踐

現場，張興華以摩拜單車為例，詳細解讀了騰訊是如何幫助用戶做架構規劃的。摩拜今年年初從其他云遷到騰訊云，開始摩拜的架構包括流量相對比較小，架構也相對簡單。但是這里有一個問題是在邏輯層沒有做拆分，只做了單一 Region 的部署。隨著業務的發展，這樣的架構已經無法滿足需求。

騰訊云對摩拜單車進行了整體架構優化，將整體安全接入摩拜架構體系，并在路由層及業務邏輯層進行了核心功能業務拆分，做到微服務化；在數據層面，實現了 Mongo 定制化優化，Mysql 性能定制優化，同時深度整合了騰訊云的云 API，構建了摩拜的 Devops 系統，快速穩步發展。在運營管理上，騰訊云給摩拜推出黑石 + 大數據的方案，黑石 +Docker 的解決方案，能夠快速的去構建、部署和擴展，形成了一個比較通用的高可用架構設計。張興華表示，對于快速成長企業來說，隨著技術架構的演進，企業需要提前做業務的拆分與規劃，支持高可用、可擴展，做到多地域雙活與多活部署。

讓云端開發更簡單的無服務架構

在微服務還方興未艾的時候，無服務架構就以其彈性伸縮、按需付費以及無維護等特點得到了很多開發者的青睞。騰訊架構平臺部技術專家陳杰表示，無服務架構的核心理念就是給整個服務提供一種公共的架構，針對性解決服務的接入、安全、擴容、容災、分布等一系列問題。

騰訊云的無服務器架構包含兩個部分組成，第一個是 FAAS（函數即服務），提供可計算的云服務，這是無服務器的核心部分。第二個是 BAAS（后端即服務），包括云對象存儲、云數據庫、云消息隊列等。企業可以在云函數里面執行還可以訪問各類的云服務，這樣的話，云函數不僅是一種定制的計算，還可以作為整個云平臺的融合器，大家可以把云函數加上后臺服務當成一個有機的整體。

云函數價值主要體現在四個方面。1）簡化架構，云函數是以函數粒度來組織的服務，是一種天生的微服務架構；2）簡化開發，無需關注底層硬件配置、OS 等，只需撰寫最核心業務邏輯，實現代碼及服務；3）簡化運維，對于云函數而言，無須關心服務器的運維和服務本身的配置，它又是一種天然的 Devops；4）是減少支出，云函數可以解決云主機 80% 以上的成本閑置的問題，因為它只有了請求才分配資源。

無服務架構 VS 傳統開發模式

那么，無服務架構和傳統開發模式項目，有哪些優劣呢？下圖從架構設計、代碼開發、代碼調試等六個角度分析了這二者的收益或不足。

從以上對比不難看出，云函數的特點包括按需實時分配函數實例、函數實例擴縮容速度很快、按實際使用計費等，比較適合用于構建無狀態微服務，對于有明顯波峰波谷效應的服務，有明顯的成本優勢。但不太適合延時非常敏感（<20ms）或持續計算時間非常長（>5 分鐘）的場景。目前，騰訊推出了 SCF 無服務器云函數，云函數會為大家準備一個免費額度包，如果是低頻調用的服務，很大可能無須支付任何費用，感興趣的開發者可以前往體驗。

寫在最后

DevOps 雖然火熱，但它的落地卻也并非是一蹴而就的，需要通過全局思考、統一規劃，在反復實踐中逐步改進和完善，最終才能根據不同的業務特性，提供一套完整體系化的運維解決方案。在騰訊多年的運營經驗中，DevOps 雖是貫穿整個應用軟件生命周期的，現在的發布完成依然并非終點。

拓展知識：

tapd登錄

權限設計不管在C端還是B端產品產品設計中都避免不了，了解權限設計思路是產品經理在職業發展的道路上必不可少的一步。特別是B端產品設計，每個新功能的增加都需要考慮權限，本文主要目的帶著你了解目前主流的用戶權限是如何設計的。

本文主要分為以下三個部分：

為什么要做權限設計？

怎么做：RBAC模型介紹

常見應用案例：C端&B端

擴展

在文明的社會，每個人都生活在秩序當中，生活需要秩序，同樣產品設計中也需要秩序，這種秩序的表達就是用戶權限。做用戶權限設置是為了更好的管理用戶，從而達到良好的產品運轉機制。B端產品通過權限設計可以相當大的資源外漏，從而降低企業風險。

RBAC模型目前是大部分公司主流的權限管理，因**自助訪問控制（DAC）和強制訪問控制（MAC）兩者的優點。

RBAC是Role-BasedAccess Control的英文縮寫，意思是基于角色訪問控制。RBAC實際上就是針對產品去發掘需求時所用到的Who（角色）、What（擁有什么資源）、How（有哪些**作）的方式。在RBAC模型中，who、what、how構成了訪問權限三元組，也就是“Who對What進行How的**作。

RBAC主要包含四個子模型：RBAC0、RBAC1、RBAC2和RBAC3，整體又叫做RBAC96。

RBAC0：

RBAC0是RBAC96模型家族中的基礎，也稱作核心部分，RBAC1、RBAC2和RBAC3是在此基礎之上發展演變而來。我們看到的可以理解它是由四個部分組成：用戶、角色、會話、權限，這就導致了這種分配關系是多對多：用戶對應多個角色、角色對應多個權限。用戶與會話一對一，會話與角色一對多；如下圖：

RBAC1：

RBAC1是在RBAC0模型基礎之上增加了角色分層概念和角色之間的繼承關系。角色分層指的是同一個角色可以用不同等級，不同等級又對應著不同的權限；角色繼承關系指的是角色之間可以轉移權限，比如A員工離職、B員工入職，兩人處于同一角色。管理員可以將A員工的權限轉移B員工頭上。如下圖：

RBAC2：

RBAC1是在RBAC0模型基礎之上增加了角色約束，主要約束哪些**作是可進行，哪些是不可進行。主要約束有以下三個方面：

角色互斥約束：是指在系統運行中,只可以同時激活運行時互斥角色**中的一個角色;

角色基數約束：是限制某一個用戶最多被分配或者激活的角色數目,或者限制某一個角色最多被賦予的權限數目;

先決條件角色約束：是指某些用戶只有在己經擁有特定角色的前提下,才能被分配到某種角色,或者某種角色只有在已經被分配到特定權限的前提下,才能被賦予某些權限。如下圖：

RBAC3：

RBAC3則是集聚了RBAC1和RBAC2的全部特點,同時將角色繼承關系和約束條件關系兩者都融入到模型中。如下圖：

RBAC模型通過給新用戶分配相應的角色即可授予其相應的訪問權限,這種靈活的角色映射機制大大降低了管理的復雜性,提高了系統的可擴展性。模型主要解決用戶對資源的訪問控制問題,即判定用戶對資源擁有怎樣的訪問權限，我們根據實際的業務需求基于RBAC模型進行組合和分離。

C端：以PMCAFF為例

PMCAFF因業務較簡單，所以權限設置并不復雜；大部分C端產品權限設計都會涉及登錄和不登錄兩種狀態，對應也就是擁有的**作權限的異同了。

B端：以TAPD、藍湖為例

TAPD使用了RBAC模型中的用戶-權限，并未加上角色這個概念，但其拓展了用戶組的概念。這就是基于RBAC模型結合自身實際業務的延伸方案。如下圖：

藍湖作為設計師切圖管理工具，便捷設計師切圖與開發人員之間的溝通，其權限設計雖不復雜，但使用了RBAC模型中的用戶-角色-權限這組經典的三元組合：用戶-角色-權限，但它的設計也是經過變形而來，為了**作簡便，直接設定好角色和權限之間的關聯：如編輯者（編輯畫布、管理設計圖、批注）

用戶擴展為用戶組或增加用戶組的概念：如用戶屬于設計組，這個組的權限可能有10個，對應其中可能涉及用戶角色（職位高低）有所增減，所以在大型公司會設用戶組，或直接像TAPD一樣使用組來配合權限管理。備注：這個用戶組也可能叫做崗位，是某一類的**，所以不要糾結名字。

權限-權限組：如專注OA20多年的泛微集團，會將權限細分到不能細分的點，然后由管理員根據自身業務需求進行配置權限組，進而關聯對應的角色或者用戶，如下圖：

1.云計算環境下RBAC模型的研究與設計_翟馨沂

2.： 君臨天下夜未央 -RBAC權限模型簡介