亚洲色成人网站www永久,亚洲欧美人成视频一区在线,亚洲国产成人高清在线观看,亚洲精品久久久久久动漫,亚洲国产精品久久电影欧美

隨著 ToB （企業(yè)服務(wù)）的興起和 ToC （消費互聯(lián)網(wǎng)）產(chǎn)品進入成熟期,線上故障帶來的損失越來越大,代碼質(zhì)量越來越重要,而「質(zhì)量內(nèi)建」正是 DevOps 核心理念之一。本次 CODING DevOps 代碼質(zhì)量實戰(zhàn)系列第一課： 《 DevOps 代碼質(zhì)量實戰(zhàn)：代碼規(guī)范與 Git Flow 》 ,將由 CODING 布道師、CODING DevOps 架構(gòu)師 楊周 老師主講,為同學(xué)們詳細講解提高代碼質(zhì)量的最佳實踐,不只適合新項目,也為老項目提供完善的漸進式方案。
課程主題
DevOps 代碼質(zhì)量實戰(zhàn)：代碼規(guī)范與 Git Flow
課程時間
8 月 11 日（周二） 19:00
課程講師
楊周
CODING 布道師
CODING DevOps 架構(gòu)師
連續(xù)創(chuàng)業(yè)者、DIY/Linux 玩家、知乎小 V,曾在創(chuàng)新工場、百度擔(dān)任后端開發(fā)。十余年一線研發(fā)和帶隊經(jīng)驗,經(jīng)歷了 ToB 、ToC 、O2O 、國內(nèi)、出海各種項目,見證了云計算時代的誕生,擅長研發(fā)最佳實踐：Code Review 、DevOps 、Git Workflow 、敏捷開發(fā)、架構(gòu)、極客辦公硬件。
課程大綱 Code Review Lint：增量檢查代碼規(guī)范 Git workflow Fork：修改第三方包
掃描 海報二維碼 即可預(yù)約系列課程

一款產(chǎn)品從設(shè)計、開發(fā)到上線,最初的靈感可能會在不同工具間流轉(zhuǎn),團隊內(nèi)會產(chǎn)生大量額外的操作、溝通和消耗。
為了打破這些壁壘,讓工作流程更暢通,團隊能專注于打磨產(chǎn)品, CODING 與在線產(chǎn)品原型設(shè)計與協(xié)作平臺 墨刀 合作推出實用小功能 —— CODING 事項內(nèi)的上傳附件功能現(xiàn)已支持 從外部引入墨刀原型 。
在事項當(dāng)前頁直接查看設(shè)計原型圖,團隊內(nèi)部能夠更加快捷高效地對設(shè)計原型進行討論、修改、更新,帶來更加順滑的工作體驗。 CODING 標準版現(xiàn)已 完全免費 , 不限人數(shù)使用！
操作指南
簡單 3 步實現(xiàn)墨刀原型引入
1 、登錄 墨刀 ,選擇需要導(dǎo)入進事項的墨刀原型,點擊 [分享] 按鈕,選擇 [嵌入第三方] 并復(fù)制代碼。
2 、前往 CODING 事項管理,進入任意史詩、需求、任務(wù)或缺陷中,在添加附件中選擇 [外部引入] - [墨刀原型] 。
3 、通過粘貼墨刀的嵌入代碼,將原型與事項關(guān)聯(lián),就能在 CODING 中直接查看設(shè)計原型了！
CODING 標準版現(xiàn)已完全免費, 點擊了解更多

CODING DevOps 8 月直播課來了~！這次 CODING 為大家?guī)砹藘蓤鱿盗兄辈フn,每系列包含 3 節(jié)課程,循序漸進,由淺入深,爭取在每晚 1 小時的課時內(nèi),結(jié)合實例為各位同學(xué)帶來最豐富的學(xué)習(xí)內(nèi)容。
那么一起來看看課程詳情以及報名方式,文末還有福利活動,千萬別錯過——
8 月直播課 第一系列
CODING DevOps 代碼質(zhì)量實戰(zhàn)系列直播課
開課時間
8 月 11 日 - 13 日,每晚 19:00 - 20:00
隨著 ToB （企業(yè)服務(wù)）的興起和 ToC （消費互聯(lián)網(wǎng)）產(chǎn)品進入成熟期,線上故障帶來的損失越來越大,代碼質(zhì)量越來越重要,而「質(zhì)量內(nèi)建」正是 DevOps 核心理念之一?！?CODING DevOps 代碼質(zhì)量實戰(zhàn)系列直播課》將詳細講解提高代碼質(zhì)量的最佳實踐,不只適合新項目,也為老項目提供完善的漸進式方案。
課程安排
《 DevOps 代碼質(zhì)量實戰(zhàn)：代碼規(guī)范與 Git Flow 》
《 DevOps 代碼質(zhì)量實戰(zhàn)（ PHP 版）》
《 DevOps 代碼質(zhì)量實戰(zhàn)（ Java 版）》
講師
楊周 - CODING 布道師、CODING DevOps 架構(gòu)師
掃描海報二維碼
回復(fù) [ 1 ] 立即報名
8 月直播課 第二系列
CODING DevOps 微服務(wù)項目實戰(zhàn)系列直播課
開課時間
8 月 18 日 - 20 日,每晚 19:00 - 20:00
近年來,工程項目的結(jié)構(gòu)越來越復(fù)雜,需要接入合適的持續(xù)集成流水線形式,才能滿足更多變的需求,《 CODING DevOps 微服務(wù)項目實戰(zhàn)系列直播課》將與大家一同探討為什么現(xiàn)代開發(fā)活動需要 DevOps,并通過示例介紹持續(xù)集成流水線的進階能力、結(jié)合 Demo 深入講解如何在 Kubernetes 集群進行灰度發(fā)布,幫助大家解放重復(fù)性勞動,更優(yōu)雅地提升生產(chǎn)效率,更快交付成果。
課程安排
《 DevOps 微服務(wù)項目實戰(zhàn)：DevOps 初體驗》
《 DevOps 微服務(wù)項目實戰(zhàn)：CI 進階用法》
《 DevOps 實戰(zhàn)：基于 Nginx-ingress 的自動化灰度發(fā)布》
講師
王寬 - CODING DevOps 開發(fā)工程師
何晨哲 - CODING DevOps 全棧工程師
王煒 - CODING DevOps 后端開發(fā)工程師
掃描海報二維碼
回復(fù) [ 2 ] 立即報名
福利環(huán)節(jié)
成功 報名課程 ,并轉(zhuǎn)發(fā)本文或活動海報至 朋友圈
集贊滿 30 贈送 CODING 洋蔥猴 小抱枕一只
集贊滿 50 贈送 CODING 洋蔥猴 大抱枕一只
掃描海報二維碼
添加 [ CODING 服務(wù)小助手] 并發(fā)送截圖
您的洋蔥猴抱枕正翹首以待~

我目前是 github+coding+自建的 Gitea,github 主要用來分享、展示一些代碼(同性交友？),大部分倉庫在這三個平臺都同步更新。三家都挺穩(wěn)定的。GitHub 很穩(wěn)定的一直被 ban ； Coding 還沒遇見過不穩(wěn)定的情況；自建的 Gitea 也還可以,具體看服務(wù)器吧。 以前掛了幾個靜態(tài)頁面在 GitHub,前段時間在 Coding 也搞了一下,試用幾天后覺得還不錯,就把網(wǎng)址解析改到 Coding pages 了。目前沒出現(xiàn)訪問不穩(wěn)定的問題。 Github Action 和 Coding 的 持續(xù)集成都在用,免費的額度都不少,Github Action 就不說了,Coding 的 持續(xù)集成是基于 Jenkins 的,挺好用的。 比較私密的東西都在自建的 Gitea 。 或許有人會說為啥不用 Gitee,我個人覺得 Gitee 的界面實在是不合我胃口。我現(xiàn)在只在需要下 github 上的一些資源,但網(wǎng)絡(luò)不太方便時才會用到 Gitee(登錄碼云克隆要用到的 github 倉庫,然后下載之,emmm,有點像反代??)；碼云的訪問在國內(nèi)是最快的,官方還有一個項目叫碼云極速下載,里面鏡像了很多 GitHub 知名項目,并且一直在更新；還有對于免費用戶受限的 Pages 服務(wù)。其他的細節(jié)就不甚了解了。 有很多老用戶說以前的東西丟了,大概率是沒找到,我自己在以前的 coding 上也上傳了一點東西,并沒丟(可能是因為我一直沒換手機號),他們給我都遷移到團隊版了,現(xiàn)在只有團隊版了,5 人以下團隊永久免費用所有服務(wù)(對于我這種個人用戶是絕對夠用了) 因為現(xiàn)在 Coding 也是我主要用的平臺了,當(dāng)然希望 Coding 越來越好啦,現(xiàn)在的體驗挺好的,而且背靠騰訊云這個大樹應(yīng)該不會輕易垮掉吧??。就我接觸過的來講,騰訊云 /coding 這一套比華為云的 devcloud 好用,且好看??。 以上觀點來自一個沒怎么接觸實際業(yè)務(wù)的學(xué)生 我看到有 V 友說了有個叫 teambition 的似乎也不錯,回頭試試去(他家網(wǎng)站 ico 好像湯不熱啊??) -------------------------------- teambition 差評,注冊賬號必須手機驗證碼,然鵝我等了半天,試了兩次都沒收到驗證碼,不整了,滾回去學(xué)習(xí)了

作者：王煒,CODING DevOps 后端開發(fā)工程師,擁有多年研發(fā)經(jīng)驗,云原生、DevOps 、Kubernetes 資深愛好者,Servicemesher 服務(wù)網(wǎng)格中文社區(qū)成員。獲得 Kubernetes CKA 、CKAD 認證。
前言
在 Kubernetes 上的應(yīng)用實現(xiàn)灰度發(fā)布,最簡單的方案是引入官方的 Nginx-ingress 來實現(xiàn)。
我們通過部署兩套 deployment 和 services,分別代表灰度環(huán)境和生產(chǎn)環(huán)境,通過負載均衡算法,實現(xiàn)對兩套環(huán)境的按照灰度比例進行分流,進而實現(xiàn)灰度發(fā)布。
通常的做法是當(dāng)項目打包新鏡像后,通過修改 yaml 文件的鏡像版本,執(zhí)行 kubectl apply 的方式來更新服務(wù)。如果發(fā)布流程還需要進行灰度發(fā)布,那么可以通過調(diào)整兩套服務(wù)的配置文件權(quán)重來控制灰度發(fā)布,這種方式離不開人工執(zhí)行。如果項目數(shù)量多,灰度的時間跨度過長,人為誤操作的概率將大大增加,過于依賴于人工執(zhí)行,這對于 DevOps 工程實踐是不能忍受的。
那么,有沒有一種方式能夠?qū)崿F(xiàn)無需人工干預(yù)的自動化灰度呢？例如在代碼更新后,自動發(fā)布到預(yù)發(fā)布和灰度環(huán)境,并在一天的時間內(nèi)自動將灰度比例從 10% 權(quán)重提高到 100%,且能夠隨時終止,灰度通過后自動發(fā)布到生產(chǎn)環(huán)境？
答案是肯定的,利用 CODING DevOps 就能夠滿足此類需求。
Nginx-ingress 架構(gòu)和原理
迅速回顧一下 Nginx-ingress 的架構(gòu)和實現(xiàn)原理：
Nginx-ingress 通過前置的 Loadbalancer 類型的 Service 接收集群流量,將流量轉(zhuǎn)發(fā)至 Nginx-ingress Pod 內(nèi)并對配置的策略進行檢查,再轉(zhuǎn)發(fā)至目標 Service ,最終將流量轉(zhuǎn)發(fā)至業(yè)務(wù)容器。
傳統(tǒng)的 Nginx 需要我們配置 conf 文件策略。但 Nginx-ingress 通過實現(xiàn) Nginx-ingress-Controller 將原生 conf 配置文件和 yaml 配置文件進行了轉(zhuǎn)化,當(dāng)我們配置 yaml 文件的策略后, Nginx-ingress-Controller 將對其進行轉(zhuǎn)化,并且動態(tài)更新策略,動態(tài) Reload Nginx Pod ,實現(xiàn)自動管理。
那么 Nginx-ingress-Controller 如何能夠動態(tài)感知集群的策略變化呢？方法有很多種,可以通過 webhook admission 攔截器,也可以通過 ServiceAccount 與 Kubernetes Api 進行交互,動態(tài)獲取。 Nginx-ingress-Controller 使用后者來實現(xiàn)。所以在部署 Nginx-ingress 我們會發(fā)現(xiàn) Deployment 內(nèi)指定了 Pod 的 ServiceAccount,以及實現(xiàn)了 RoleBinding,最終達到 Pod 能夠與 Kubernetes Api 交互的目的。
實現(xiàn)方案預(yù)覽
為了實現(xiàn)以上目標,我們設(shè)計了以下持續(xù)部署流水線。
此持續(xù)部署流水線主要實現(xiàn)了以下幾個步驟： 自動部署到預(yù)發(fā)布環(huán)境 是否進行 A/B 測試 自動灰度發(fā)布（自動進行 3 次逐漸提升灰度比例） 發(fā)布到生產(chǎn)環(huán)境
同時,本文案例還演示了從 Git 提交代碼到自動觸發(fā)持續(xù)集成的步驟： 提交代碼后觸發(fā)持續(xù)集成,自動構(gòu)建鏡像 鏡像構(gòu)建完成后,自動推送鏡像到制品庫 觸發(fā)持續(xù)部署
1 、提交代碼后觸發(fā)持續(xù)集成,自動構(gòu)建鏡像并推送到制品庫
2 、觸發(fā)持續(xù)部署,并發(fā)布到預(yù)發(fā)布環(huán)境
3 、人工確認：進行 A/B 測試（或跳過直接進入自動灰度）
進行 A/B 測試時,只有 Header 包含 location=shenzhen 可以訪問新版本,其他用戶訪問生產(chǎn)環(huán)境仍然為舊版本。
4 、人工確認：是否自動灰度發(fā)布（自動進行 3 輪逐漸提升灰度比例,每輪間隔 30s ）
第一次灰度：新版本 30% 的灰度比例,此時訪問生產(chǎn)環(huán)境大約有 30% 的流量進入新版本灰度環(huán)境：
30s 后自動進行第二輪灰度：新版本 60% 的灰度比例：
60s 后自動進行第三輪灰度：新版本 90% 的灰度比例：
本案例中,我們配置了自動化灰度發(fā)布將會以 3 次漸進式進行,每次提高 30% 的比例,每次持續(xù) 30s 后自動進入下一個灰度階段。在不同的灰度階段,會發(fā)現(xiàn)請求新版本出現(xiàn)的概率越來越高。漸進式的灰度可根據(jù)業(yè)務(wù)需要進行任意配置,例如持續(xù) 1 天時間分 10 次自動進行灰度,直至發(fā)布到生產(chǎn)環(huán)境而無需人工值守。
5 、灰度完成,30s 后發(fā)布到生產(chǎn)環(huán)境
項目源碼和原理分析
項目源碼地址： https://wangweicoding.coding.net/public/nginx-ingress-gray/nginx-ingress-gray/git ├── Jenkinsfile # 持續(xù)集成腳本 ├── deployment │ ├── canary │ │ └── deploy.yaml # 灰度發(fā)布部署文件 │ ├── dev │ │ └── deploy.yaml # 預(yù)發(fā)布部署文件 │ └── pro │ └── deploy.yaml # 生產(chǎn)部署文件 ├── docker │ ├── Dockerfile │ └── html │ └── index.html ├── nginx-ingress-init │ ├── nginx-ingress-deployment # nginx-ingress 部署文件 │ │ ├── ClusterRoleBinding.yaml │ │ ├── RoleBinding.yaml │ │ ├── clusterRole.yaml │ │ ├── defaultBackendService.yaml │ │ ├── defaultBackendServiceaccount.yaml │ │ ├── deployment.yaml │ │ ├── nginxDefaultBackendDeploy.yaml │ │ ├── roles.yaml │ │ ├── service.yaml │ │ └── serviceAccount.yaml │ └── nginx-ingress-helm # nginx-ingress Helm 包 │ └── nginx-ingress-1.36.3.tgz └── pipeline # 持續(xù)部署流水線模板 ├── gray-deploy.json # 灰度發(fā)布流水線 ├── gray-init.json # 灰度發(fā)布初始化（首次運行） └── nginx-ingress-init.json # nginx-ingress 初始化（首次運行）
灰度環(huán)境和生產(chǎn)環(huán)境主要由 deployment/canary/deploy.yaml 和 deployment/pro/deploy.yaml 來實現(xiàn),主要是實現(xiàn)了兩套環(huán)境的： Deployment Service Ingress
A/B 測試和灰度由配置的 Ingress 進行控制： apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx # nginx=nginx-ingress| qcloud=CLB ingress nginx.ingress.kubernetes.io/canary: "true" # 開啟灰度 nginx.ingress.kubernetes.io/canary-by-header: "location" # A/B 測試用例 Header key nginx.ingress.kubernetes.io/canary-by-header-value: "shenzhen" # A/B 測試用例 Header value name: my-ingress namespace: pro spec: rules: - host: nginx-ingress.coding.pro http: paths: - backend: serviceName: nginx-canary servicePort: 80 path: /
A/B 測試主要由注解 nginx.ingress.kubernetes.io/canary-by-header 和 nginx.ingress.kubernetes.io/canary-by-header-value 進行控制,來匹配請求 Header 的 Key 和 Value 。 apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx # nginx=nginx-ingress| qcloud=CLB ingress nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: 30 name: my-ingress namespace: pro spec: rules: - host: nginx-ingress.coding.pro http: paths: - backend: serviceName: nginx-canary servicePort: 80 path: /
而灰度則由注解 nginx.ingress.kubernetes.io/canary-weight 控制,值范圍可以是 0-100 ,對應(yīng)灰度權(quán)重比例。在 Nginx-ingress ,負載均衡算法主要由 加權(quán)輪詢 的算法來實現(xiàn)分流。
整體架構(gòu)圖如所示：
環(huán)境準備 K8S 集群,推薦使用騰訊云 容器服務(wù) ； 開通 CODING DevOps ,提供鏡像構(gòu)建和流水線的部署能力。
實踐步驟
1 、克隆源碼并推送至自己的 CODING Git 倉庫 ``` $ git clone https://e.coding.net/wangweicoding/nginx-ingress-gray/nginx-ingress-gray.git $ git remote set-url origin https://you coding git $ git add . $ git commit -a -m 'first commit' $ git push -u origin master ```
注意,推送前請將 deployment/dev 、 deployment/canary 、 deployment/pro 文件夾的 deploy.yaml image 修改為自己的制品庫鏡像地址。
2 、創(chuàng)建持續(xù)集成流水線
使用“自定義構(gòu)建過程”創(chuàng)建構(gòu)建計劃,并選擇使用代碼倉庫的 Jenkinsfile
3 、新增云賬號并創(chuàng)建持續(xù)部署流水線,復(fù)制項目的 pipeline Json 模板到創(chuàng)建的流水線內(nèi)（ 3 個）
為了便于使用模板,創(chuàng)建持續(xù)部署流水線應(yīng)用名為：nginx-ingress
創(chuàng)建繼續(xù)創(chuàng)建空白部署流程,復(fù)制 Json 模板到持續(xù)部署流水線中,一共創(chuàng)建三條流水線： nginx-ingress-init - 用于初始化 nginx-ingress gray-init - 用于首次初始化環(huán)境 gray-deploy - 用于演示灰度發(fā)布 注意：請將以上流水線的云賬號選擇為自己的云賬號,另外 gray-deploy 流水線中,請重新配置“啟動所需制品”和“觸發(fā)器”。
4 、初始化 nginx-ingress （首次運行）
首次運行 nginx-ingress 流水線將自動為您部署 nginx-ingress 。部署成功后,運行 kubectl get svc | grep nginx-ingress-controller 獲取 Ningx-ingress 的 EXTERNAL-IP ,此 IP 為集群請求入口 IP 。并為本機配置 Host ,便于訪問。
5 、初始化灰度發(fā)布（首次運行）
首次運行 gray-init 流水線將自動部署一套完整的環(huán)境,否則自動化灰度流水線將會失敗。
6 、自動觸發(fā)灰度發(fā)布
現(xiàn)在,您可以嘗試修改項目 docker/html/index.html 文件,推送后將自動觸發(fā)構(gòu)建和持續(xù)部署,觸發(fā)后,進入“持續(xù)部署”頁面,查看部署詳情和流程。
總結(jié)
我們主要利用了 CODING 持續(xù)部署 的 等待 階段,通過對不同灰度比例的階段設(shè)定等待時間,自動化逐一運行灰度階段,最終實現(xiàn)無人工值守的自動化灰度發(fā)布。
利用 等待 階段,可以實現(xiàn)平滑的發(fā)布流程,只有當(dāng)發(fā)布出現(xiàn)問題,才需要人工介入。配合持續(xù)部署通知功能,可以很方便的將當(dāng)前發(fā)布狀態(tài)推送到企業(yè)微信、釘釘?shù)葏f(xié)作工具。
為了方便展示,案例中對灰度比例和等待時間進行了硬編碼,你也可以使用階段的“自定義參數(shù)”來實現(xiàn)對灰度比例和等待實現(xiàn)進行動態(tài)控制,針對當(dāng)前的發(fā)布等級動態(tài)輸入灰度比例和流程控制,使得發(fā)布更加靈活。
生產(chǎn)建議
本文的 Nginx-ingress 采用 deployment 的部署方式來實現(xiàn)。 Nginx-ingress 作為 Kubernetes 集群的邊緣網(wǎng)關(guān),承擔(dān)著所有入口流量,其高可用性直接決定了 Kubernetes 集群的高可用性。
在生產(chǎn)環(huán)境,部署 Nginx-ingress 建議遵循以下幾點： 推薦使用 DaemonSet 的方式部署,避免節(jié)點故障。 通過標簽選擇器,將 Nginx-ingress-controller 部署在獨立的 Node 節(jié)點（如高主頻、高網(wǎng)絡(luò)、高 IO 節(jié)點）或者低負載的節(jié)點。 如果采用 Deployment 的方式部署,可以為 Nginx-ingress 配置 HPA 水平伸縮。

服務(wù)不停歇,運維不休息。運維的工作長達 7x24 小時,故而每年的 7 月 24 日被視為運維日,代表著運維全天候的保障系統(tǒng)穩(wěn)定,維護業(yè)務(wù)正常運行,時刻準備著一線工作的召喚。
騰訊運維技術(shù)開放日 是由騰訊云,TEG 技術(shù)工程事業(yè)群,及 CODING DevOps 共同發(fā)起的,面向運維人員的技術(shù)開放日。旨在分享和交流騰訊內(nèi)部在運維方面的實踐經(jīng)驗,打造騰訊內(nèi)部與外部共同交流、共同進步的運維技術(shù)生態(tài)圈。
第二屆騰訊運維技術(shù)開放日,將邀請 包括 CODING 高級技術(shù)專家周紀海在內(nèi)的四位騰訊內(nèi)部講師 ,分享騰訊在微服務(wù)致力、集群管理、DevOps 、持續(xù)部署等領(lǐng)域的實踐經(jīng)驗和獨到見解,與現(xiàn)場參與者共同探討運維進階之路。
活動時間
2020 年 7 月 23 日 19:30
講師陣容
↑ 掃描上方二維碼 ↑
第二屆騰訊運維技術(shù)開放日等你來！

在敏捷研發(fā)的過程中,或者項目結(jié)束后的復(fù)盤階段,度量并分析團隊成員在周期內(nèi)的工作負荷、完成的工作量與工作動態(tài),能夠讓管理者清晰的認識到團隊成員的工作負載與工作效率；團隊成員間也可以相互查看對方所參與的項目,近期工作動態(tài)或近期事項。
效能度量的主要功能為統(tǒng)計團隊成員在一段時間內(nèi)的計劃事項數(shù)、完成事項數(shù)和所編輯的 Wiki 數(shù)以供分析。這些數(shù)據(jù)將會在趨勢面板上進行顯示。并且還可以自行設(shè)置分組并添加其它成員,方便快速查看團隊成員近期工作概覽。
使用準備
團隊擁有者或管理員在 [團隊管理] -> [權(quán)限配置] 中為相應(yīng)的用戶組的勾選「效能度量」的「查看頁面」權(quán)限。勾選完成后處于該用戶組的成員的工作臺會出現(xiàn)效能度量的功能入口。
趨勢面板
面板將會反映所添加成員的工作量趨勢圖,以三個數(shù)據(jù)維度進行展示：計劃事項數(shù)、完成事項數(shù)和 Wiki 編輯數(shù)?？梢赃x擇日、周、月三種統(tǒng)計周期視圖進行查看,通過下方的滾輪橫軸進行左右拖拉日期。
計劃事項數(shù)
將會統(tǒng)計處理人在一個時間周期內(nèi)開始和截止時間所安排的事項總數(shù),納入統(tǒng)計的事項包含史詩、需求、任務(wù)、缺陷和子任務(wù)。 如果事項填寫了開始和結(jié)束時間,那么處在這個時間周期的每一天的事項數(shù) +1 ； 如果事項只填寫了開始時間,那么開始時間所在當(dāng)天事項數(shù) +1 ； 如果事項只填寫了截止時間,那么截止時間所在當(dāng)天事項數(shù) +1 。
具體的計數(shù)原理請參考 計劃事項數(shù)計數(shù)方式 。
完成事項數(shù)
將會統(tǒng)計處理人在固定周期內(nèi)完成的事項總數(shù)。這里的完成事項定義涵蓋史詩、需求、任務(wù)、缺陷和子任務(wù)。若對這些事項做出了完成操作,即狀態(tài)類型從“非已完成”到“已完成”,則視該事項被定義為完成。 如果在時間周期內(nèi)且周期結(jié)束后狀態(tài)類型仍然是“已完成”,那么完成事項數(shù) +1 。
具體的計數(shù)原理請參考 完成事項數(shù)計數(shù)方式 。
編輯 Wiki 數(shù)
將會統(tǒng)計團隊成員更新過的 Wiki 篇數(shù)。若在同一個周期內(nèi)對同一篇文檔進行修改并執(zhí)行了“提交文檔”,那么編輯 Wiki 數(shù)算為 1 篇。
添加成員與分組管理
在「添加成員」中可以通過成員姓名或搜索項目一鍵添加項目內(nèi)成員,添加進圖表的成員可移除。在「分組」下拉組件中可進行添加分組、刪除和重命名等操作,添加的成員默認進入當(dāng)前選擇的分組中。分組為用戶自行設(shè)置,并不會在團隊內(nèi)公開顯示該分組,屬于個性化查看功能。
成員工作概覽頁
在效能度量頁面中點擊任意成員,可進入成員的工作概覽頁。頁面包含： 成員名稱和頭像； 最近活躍時間； 參與的項目； 近期事項； 該成員近期的工作動態(tài)。
近期事項
近期事項的統(tǒng)計內(nèi)容包含： 已完成,查詢近 1 個月完成的事項,按照完成時間逆序排； 進行中,查詢狀態(tài)類型為“進行中”的事項,按截止時間逆序排； 未開始,查詢狀態(tài)類型為“未開始”的事項,按截止時間逆序排。
工作動態(tài)
工作動態(tài)為成員的日常協(xié)作動態(tài),可按分類查詢,包含： 項目協(xié)同 代碼倉庫 持續(xù)集成 持續(xù)部署 Wiki 文件網(wǎng)盤 ...
權(quán)限控制
該功能涉及到的權(quán)限模塊名稱為效能度量,具有“查看”權(quán)限。每個團隊的擁有者和項目管理員將默認勾選「查看功能」權(quán)限點。
計數(shù)方式詳情
計劃事項數(shù)計數(shù)方式 如果事項填寫了開始和結(jié)束時間,那么處在這個時間段里的每一天的事項數(shù) +1 ； 如果事項只填寫了開始時間,那么開始時間所在當(dāng)天事項數(shù) +1 ； 如果事項只填寫了截止時間,那么截止時間所在當(dāng)天事項數(shù) +1 。
例如表 1：
依據(jù)表 1 的數(shù)據(jù),該成員的計劃事項統(tǒng)計結(jié)果如下：
若同一個事項的時間跨越了 2 個周期,那么將在兩個周期中分別計數(shù) +1 。例如事項 A 在的開始和截止時間為 2020 年 1 月 25 日 —— 2020 年 2 月 4 日,那么事項 A 在 1 月和 2 月都被計算為 1 個事項。
完成事項數(shù)計數(shù)方式
事項在一個周期內(nèi)被做了 1 次完成動作,且周期結(jié)束后狀態(tài)類型為“已完成”,則完成事項數(shù) +1 。
事項反復(fù)打開和完成的計算方式 事項在一個周期內(nèi)被完成過,但周期結(jié)束前狀態(tài)類型為“已完成”,則完成事項數(shù) +1 ； 事項在一個周期內(nèi)被完成過,但周期結(jié)束前狀態(tài)類型為非“已完成”,則不貢獻完成事項數(shù)； 事項在第一個周期內(nèi)被完成,直到第二個周期才被打開,且第二個周期結(jié)束前狀態(tài)類型為“已完成”,則這兩個周期內(nèi)完成事項數(shù)分別 +1 。
例如表 2,為事項 A 在 1-4 月的狀態(tài)情況：
那么事項 A 在 1-4 月被計算的完成事項數(shù)分別為：1,0,1,0 。 關(guān)于 CODING,了解更多

背景
如何做團隊技術(shù)文章分享和沉淀？這是一個老生常談的話題。常見的技術(shù)選型可以是 Confluence 、Dokuwiki 、Gitbook 等。
但對于敏捷團隊來說,這些都不夠優(yōu)雅,我們希望能把技術(shù)文章像代碼一樣進行協(xié)作和版本管理。更新技術(shù)文章后,能夠自動部署到公司的 K8S 集群。那么,CODING DevOps + Hexo 一定是你的不二之選,這也是 CODING 目前的實踐。
Hexo 是一個快速、簡潔且高效的博客框架。我們只需要書寫 Markdown 格式的技術(shù)文章,通過命令能夠直接生成靜態(tài)頁面,方便瀏覽和部署。
本文將介紹如何使用 CODING DevOps 建立流水線,推送技術(shù)文章到 Git 倉庫后,自動觸發(fā)流水線執(zhí)行構(gòu)建并部署到 K8S 集群。
準備 K8S 集群,推薦使用騰訊 TKE 開通 CODING DevOps 克隆代碼倉庫： https://wangweicoding.coding.net/public/blog/blog/git
實現(xiàn)效果 提交新文章,自動觸發(fā)構(gòu)建流程 生成靜態(tài)頁面,構(gòu)建 Docker 鏡像 鏡像構(gòu)建成功,自動觸發(fā)部署流程 部署成功,新文章發(fā)布
實踐步驟
1. 克隆代碼并推送到自己的 CODING Git 倉庫 git clone https://e.coding.net/wangweicoding/blog.git git remote set-url origin [CODING Git Url] git push
2. 開通 CODING 制品庫
開通 Docker 類型的制品庫,并記錄倉庫地址和制品庫名稱,將在下一個階段用到。
3. 開通 CODING 持續(xù)集成,并配置構(gòu)建任務(wù)
選擇“自定義構(gòu)建過程”,并配置來源使用代碼倉庫的 Jenkinsfile
項目內(nèi)的 Jenkinsfile 主要是用來生成靜態(tài)頁面,以及構(gòu)建鏡像并推送鏡像到制品庫。 pipeline { agent any stages { stage('檢出') { steps { checkout([ $class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]] ]) } } stage('生成靜態(tài)頁面') { steps { script { sh 'npm install -g hexo-cli' # 安裝 Hexo sh 'npm install' # 安裝依賴 sh 'hexo g' # 生成靜態(tài)頁面 } } } stage('構(gòu)建') { steps { echo '構(gòu)建中...' script { // 此處請修改 dockerServer 、dockerPath 、imageName 替換為自己項目的值 dockerServer = 'wangweicoding-docker.pkg.coding.net' dockerPath = '/blog/blog' imageName = "${dockerServer}${dockerPath}/blog:${env.GIT_BUILD_REF}" def customImage = docker.build(imageName) // 推送 Docker 鏡像到倉庫 docker.withRegistry("https://${dockerServer}", CODING_ARTIFACTS_CREDENTIALS_ID) { customImage.push() } } } } } }
注意：請將 Jenkinsfile 內(nèi)變量 dockerServer 、dockerPath 、imageName 修改為自己的制品庫地址、制品庫名 、制品名。
4. 開通 CODING 持續(xù)部署,并配置 K8S 云賬號
進入“團隊管理” -> "部署設(shè)置",配置 Kubernetes 云賬號（ Kubeconfig 或 Service Account ）,以便 CODING 持續(xù)部署部署應(yīng)用到目標集群。
如果你是騰訊云用戶,可以按照操作提示一鍵綁定 TKE 集群。
5. 為持續(xù)部署配置應(yīng)用和部署流程
進入持續(xù)部署控制臺,點擊“創(chuàng)建應(yīng)用”,為了方便直接使用本文的部署模板,應(yīng)用名請輸入 blog ,并勾選 支持 Kubernetes 部署 。
應(yīng)用創(chuàng)建后,接下來創(chuàng)建部署流程：
復(fù)制代碼倉庫的 pipeline.json 的內(nèi)容,黏貼至部署流程的“編輯 JSON”框內(nèi)。 注意：界面中的“啟動所需制品”和“觸發(fā)器”需要重新選擇自己的項目和倉庫,并在部署 deployment 和 services 階段,重新選擇自己剛才創(chuàng)建的云賬號。
編輯完成后,點擊保存即可。
我們創(chuàng)建的持續(xù)部署流水線主要定義這幾項配置： 配置了 3 個“啟動所需制品”,并配置了默認版本。分別是： services.yaml,Kubernetes Services 部署文件,提供外網(wǎng)訪問的 LoadBalancer 。 deploy.yaml,Kubernetes Deployment 部署文件,用于更新鏡像版本。 docker 鏡像,需要自動更新的鏡像版本。 配置了 CODING Docker 倉庫 “自動觸發(fā)器”,當(dāng)鏡像構(gòu)建完成并推送到鏡像倉庫時,自動觸發(fā)部署流程。 部署 services.yaml 和 deploy.yaml 。
當(dāng)鏡像更新,觸發(fā)器自動觸發(fā),持續(xù)部署能夠直接獲取到本次構(gòu)建的版本號,通過對 deployment 鏡像版本的自動綁定,實現(xiàn)自動部署新的鏡像。
deploy.yaml apiVersion: apps/v1 kind: Deployment metadata: name: blog namespace: blog labels: app: blog spec: replicas: 2 selector: matchLabels: app: blog template: metadata: labels: app: blog spec: containers: - name: blog image: wangweicoding-docker.pkg.coding.net/blog/blog/blog # 此處的鏡像版本將被自動替換為本次構(gòu)建的版本。 ports: - containerPort: 80 imagePullSecrets: - name: dockersecret # 集群憑據(jù),需要手動創(chuàng)建
Deployment 中的 image: wangweicoding-docker.pkg.coding.net/blog/blog/blog ,image 會被 CODING 持續(xù)部署自動替換為本次構(gòu)建的鏡像版本,實現(xiàn)自動綁定 Docker 制品。所以這里只需要完整的制品 URL 即可,無需 TAG 版本號。 注意：請將 image 修改為自己的 Docker 鏡像地址。deployment 文件內(nèi)使用了 imagePullSecrets,配置部署前請使用以下方法提前創(chuàng)建。 kubectl create secret docker-registry myregcred \ --docker-server= \ --docker-username= \ --docker-password= \ -n namespace
service.yaml apiVersion: v1 kind: Service metadata: name: blog namespace: blog spec: selector: app: blog ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer # 提供 Hexo 外網(wǎng)訪問 IP
6. 發(fā)布文章
編輯項目 source/_posts/ 目錄下的文章,并推送到 CODING Git 倉庫,此時會自動觸發(fā)構(gòu)建,構(gòu)建成功后,會自動觸發(fā)博客發(fā)布的部署流程。
寫在最后
我們使用 CODING DevOps 實現(xiàn)了將 Hexo 全自動部署到 K8S 集群,能夠非常方便地對技術(shù)文章統(tǒng)一管理以及沉淀。不僅是 Hexo,其他任意構(gòu)建為 Docker 鏡像的前端和后端項目,都可以用本文的思想進行配置,實現(xiàn)自動觸發(fā),自動部署到 K8S 集群。
結(jié)合持續(xù)部署的“人工確認”階段,我們能夠很方便地實現(xiàn)發(fā)布的審批流,使得發(fā)布更加安全。另外,自動觸發(fā)器不僅可以使用 CODING Docker 鏡像倉庫觸發(fā),還能夠使用 Webhook 觸發(fā)。通過 Webhook 調(diào)用流水線,可以非常方便地將 CODING 持續(xù)部署和內(nèi)部 CI 系統(tǒng)打通,滿足更多的使用場景。
當(dāng)然,CODING 持續(xù)部署可以實現(xiàn)更多的應(yīng)用場景,例如：灰度發(fā)布、藍綠 /金絲雀發(fā)布等,我們將在后續(xù)帶給大家更多的實踐內(nèi)容。 關(guān)于 CODING,了解更多。

2020 年秋招在即,許多預(yù)備程序員即將踏入工作崗位,但是苦于沒有應(yīng)聘求職的經(jīng)驗,十分害怕在秋招中踩坑。在眾多應(yīng)聘者中,青澀的你如何才能脫穎而出呢？ 所以今天,CODING 給大家來送福利了——我們聯(lián)合猿圈學(xué)堂,為想要就業(yè) IT 崗位的小伙伴提供一次真實的企業(yè)秋招模擬筆試,模擬筆試是以比賽的形式進行,我們?yōu)榇蠹覝蕚淞顺嗒勂?表現(xiàn)優(yōu)異者還可以得到企業(yè)內(nèi)推資格！心動的話就趕快行動吧～
詳細信息和報名方式請看下方海報↓↓↓

云開發(fā)中的云函數(shù)是云開發(fā) Cloudbase 的一個重要的功能,開發(fā)者可以借助其中的云函數(shù)來實現(xiàn)一些復(fù)雜的業(yè)務(wù)邏輯,來實現(xiàn)諸如圖片處理、數(shù)據(jù)處理等復(fù)雜的邏輯。同時,云函數(shù)的免運維、快速部署等特性也可以大大簡化開發(fā)者的工作量,讓開發(fā)者把更多的精力投放在業(yè)務(wù)邏輯的開發(fā)上。
在進行云開發(fā)中云函數(shù)的開發(fā)時,我們可能會經(jīng)常重復(fù)“編寫函數(shù)代碼->部署”這個過程,這個過程繁瑣而又不得不做,有沒有一種方式可以讓機器幫我們 自動部署函數(shù) ,減少我們做這些重復(fù)的工作,把更多的精力都投放在更有價值的事情上呢？我們可以借助 CODING CI,來實現(xiàn)云函數(shù)的自動化部署,簡化我們的工作量。
接下來,我將介紹一下如何構(gòu)建一個流水線,實現(xiàn)自動化部署云開發(fā)中的云函數(shù)。

1. 工作流梳理
我們先梳理一下流水線的工作流。這是一個只有單一步驟的簡單工作流。 在推送步驟中我們還是借助 TCB CLI 工具完成云開發(fā)中云函數(shù)的部署。流程的結(jié)果我們可以通過 WebHook 消息通知到企業(yè)微信。

2. 在 CODING 中創(chuàng)建 DevOps 項目
登錄 CODING 工作臺,進入全部項目模塊,新建一個項目。 選擇新建項目時的所用到的模板,這里選擇 DevOps 模板,進入下一步。 填寫項目名稱、項目描述,完成創(chuàng)建。

3. 創(chuàng)建云開發(fā)環(huán)境
輸入網(wǎng)址： https://console.cloud.tencent.com/tcb/env/index,如果沒有授權(quán)會彈出以下畫面。 點擊訪問管理,進入授權(quán)。創(chuàng)建一個云開發(fā)環(huán)境,這里命名環(huán)境為 mytest 。

4. 設(shè)置 SecretId 和 SecretKey
在流水線中,一般不會使用特權(quán)賬號的 SecretKey （主賬號的最高權(quán)限 SecretKey,擁有騰訊云控制臺的所有權(quán)）,都是按需授權(quán),所以需要對 SecretKey 的權(quán)限進行訪問控制。使用主賬號登錄 https://console.cloud.tencent.com/cam/capi,根據(jù)提示創(chuàng)建子用戶,選擇自定義創(chuàng)建,選擇類型為可訪問資源并接收消息。填寫用戶信息,選擇訪問方式為編程訪問。 對子用戶進行權(quán)限策略關(guān)聯(lián),對于云開發(fā)產(chǎn)品的訪問控制有一個預(yù)設(shè)策略名字叫 QcloudAccessForTCBRole ,對賬號授權(quán)該策略,將擁有云開發(fā)（ TCB ）對云資源的訪問權(quán)限。直接在搜索框中搜索該策略即可。 下一步,完成子用戶的創(chuàng)建,請保存好 SecretId 和 SecretKey 信息。

5. 創(chuàng)建 TCB 云開發(fā)項目
在本地使用 TCB CLI 創(chuàng)建一個云開發(fā)項目。 tcb init 如果您沒有登錄 tcb,這里需要掃碼登錄。選擇關(guān)聯(lián)的環(huán)境,這里我選擇 mytest 環(huán)境,輸入項目名稱 mytest ,選擇開發(fā)語言,目前支持 PHP 、Java 和 Node 三種語言,這里我選擇 Node,選擇云開發(fā)模板,這里我選擇 Hello World 模板。 √ 選擇關(guān)聯(lián)環(huán)境 · mytest - [mytest-1ae5c0:空] √ 請輸入項目名稱 · mytest √ 選擇開發(fā)語言 · Node √ 選擇云開發(fā)模板 · Hello World √ 創(chuàng)建項目 mytest 成功！
我們將本地倉庫與 CODING 遠端倉庫進行關(guān)聯(lián)。 cd mytest git init #這里需要注意 username 為你的 CODING 賬戶名,tcb-fun 是代碼倉庫名 git remote add origin [email?protected] :username/tcb-fun.git git add . git commit -m "Initial commit" git push -u origin master

6. CODING CI 設(shè)置
SecretId 和 SecretKey 信息屬于敏感信息,我們需要以 CODING 憑據(jù)的形式保存在項目配置中,使用憑據(jù)后你的敏感信息將不會出現(xiàn)在構(gòu)建日志和 Jenkinsfile 中,這樣會更加安全。進入項目,依次選擇項目設(shè)置、開發(fā)者選項、憑據(jù)管理,錄入一個憑據(jù)。 CODING 為我們提供了原生調(diào)用騰訊云產(chǎn)品的能力,在這里我們選擇憑據(jù)類型為云 API 秘鑰,填寫好憑據(jù)名稱、SecretId 和 SecretKey 信息,授權(quán)在持續(xù)集成中使用憑據(jù)。 接下來我們回到項目,選擇構(gòu)建計劃模塊,創(chuàng)建一個持續(xù)集成任務(wù)。 填寫計劃名稱,選擇代碼源為 CODING 代碼倉庫,配置來源使用靜態(tài)配置的 Jenkinsfile 。 根據(jù)前面我們梳理的流程,開始撰寫 Jenkinsfile 文件,這里我們需要選擇文本編輯器。 pipeline { agent any stages { stage('檢出') { steps { echo '[檢出]正在從目標代碼庫檢出最新源碼...' checkout([ $class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[ url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID ]] ]) echo '[檢出]檢出源碼成功.' } } stage('部署') { steps { echo '[部署]準備部署云函數(shù).' sh 'npm i -g @cloudbase/cli' withCredentials([cloudApi(credentialsId: env.CREDENTIALSID, secretIdVariable: 'CLOUD_API_SECRET_ID', secretKeyVariable: 'CLOUD_API_SECRET_KEY')]){ sh 'tcb login --apiKeyId "${CLOUD_API_SECRET_ID}" --apiKey "${CLOUD_API_SECRET_KEY}"' } sh 'tcb functions:deploy --force --all' echo '[部署]部署云函數(shù)成功.' } } stage('事件消息') { steps { echo '[事件消息]持續(xù)部署流程完成.' } } } }
保存 Jenkinsfile,下一步需要我們將憑據(jù)添加到環(huán)境變量中。切換到變量與緩存選項卡,在流程環(huán)境變量中添加環(huán)境變量,變量名填寫 CREDENTIALSID,類別選擇 CODING 憑據(jù),選擇默認值為剛剛添加的憑據(jù)信息,保存修改。

7. 測試與驗證
通過以上步驟,我們已經(jīng)構(gòu)建好了云開發(fā)中云函數(shù)持續(xù)部署流水線,我們可以使用 push 代碼來觸發(fā)流水線自動部署。 在 CODING 項目的構(gòu)建計劃中可以看到每一次的構(gòu)建任務(wù)的運行狀態(tài)。 點擊構(gòu)建任務(wù),進入到任務(wù)詳情,點擊每一個步驟都可以看到日志詳情。我們看到整個流水線已經(jīng)跑完,狀態(tài)正常,在日志中也看到云開發(fā)中云函數(shù)部署成功的提示。 我們回到云開發(fā)控制臺,進入 mytest 環(huán)境,查看云函數(shù)列表,已經(jīng)可以看到我們剛剛部署的云函數(shù)。測試調(diào)用云函數(shù),其功能正常。
作者：校園布道師談笑

CODING 中提供了內(nèi)置云主機用來執(zhí)行持續(xù)集成（ CI ）中的構(gòu)建計劃,能夠勝任大部分構(gòu)建任務(wù)。但如果碰上了大型項目的構(gòu)建,或者需要在本地服務(wù)器生成構(gòu)建成果,單個計算資源就顯得有點捉急了。針對這一部分需求,CODING 現(xiàn)已支持接入第三方計算資源作為構(gòu)建節(jié)點,甚至可以接入多個服務(wù)器共同作為構(gòu)建節(jié)點池,打造專屬的計算集群。
下面將會以騰訊云 CVM 為例,演示如何在 CODING 持續(xù)集成中接入自己的計算資源。
開通安全組
在購買了 騰訊云 CVM 后,第一件要做的事情就是開放相應(yīng)的 安全組策略 ,入站和出站規(guī)則都需要設(shè)置。
登錄服務(wù)器
在 [操作] 中點擊登錄,按照提示輸入 root 密碼。如果忘記密碼可以在 [更多] > [密碼 /密鑰] 中點擊 [重置密碼] 后再次輸入即可。
做完上述操作并成功登錄服務(wù)器后,可以選擇 Docker 或 cci-agent 兩種方式將服務(wù)器接入至構(gòu)建節(jié)點池。如果想使用與 CODING 官方提供的運行節(jié)點一致的環(huán)境,請選擇使用 Docker 運行構(gòu)建節(jié)點。如果想使用節(jié)點上自帶的環(huán)境,譬如需要使用 MacOS 上的 Xcode 編譯 iOS 應(yīng)用,請選擇 cci-agent 方式進行接入。
接入構(gòu)建節(jié)點池
使用 Docker （推薦）
使用 Docker 的前提是服務(wù)器上已經(jīng)安裝了 Docker 。需要注意的是,部分 openVZ 虛擬化的服務(wù)器因內(nèi)核較低,無法成功安裝 Docker,當(dāng)然我們的騰訊云 CVM 是沒有這個問題的。下面使用 curl 命令安裝 Docker 。 curl -fsSL https://get.docker.com/ | sh
待 Docker 安裝完成后,前往 CODING 進入 [項目] > [持續(xù)集成] > [構(gòu)建節(jié)點] ,在構(gòu)建節(jié)點頁復(fù)制配置命令。
等待一小會,等鏡像構(gòu)建完成后便會提示構(gòu)建成功。
在 CODING 構(gòu)建節(jié)點頁也可以看到新注冊上線的服務(wù)器。
手動接入 cci-agent
在 CODING 的構(gòu)建節(jié)點頁一鍵生成初始化命令,并在服務(wù)器中運行該命令。
執(zhí)行 cci-agent 啟動命令。 ./cci-agent up -d
配置完成后會出現(xiàn)在節(jié)點池中。
在安裝過程中,節(jié)點狀態(tài)會不斷變化。關(guān)于節(jié)點的狀態(tài)說明： 閑置：構(gòu)建節(jié)點此時空閑。 占用：構(gòu)建節(jié)點已被分配到構(gòu)建任務(wù)中使用。 準備中：構(gòu)建節(jié)點正在準備構(gòu)建環(huán)境。 開啟：只有處于開啟狀態(tài)的節(jié)點才能被分配使用,如果關(guān)閉節(jié)點不會影響正在運行的構(gòu)建任務(wù)。 刪除：節(jié)點將會脫離 CODING 持續(xù)集成服務(wù),但只會刪除工作空間和相關(guān)的配置信息,之前產(chǎn)生的全局緩存文件仍會保留。
使用自定義節(jié)點
計算資源接入成功后,在 [構(gòu)建計劃] > [設(shè)置] 中選擇使用自定義節(jié)點。
保存修改后,觸發(fā)構(gòu)建任務(wù)后就可以在自己的計算資源集群中執(zhí)行持續(xù)集成任務(wù)了。使用自定義節(jié)點不會占用 CODING 團隊配額,不受并行上限限制。并且服務(wù)器集群規(guī)模越大,構(gòu)建大型項目的速度也會越快。
點擊查看幫助文檔了解更多

IT 運維告警現(xiàn)狀
目前 IT 運維領(lǐng)域保證服務(wù)運行正常的主要方法是對相關(guān)運維指標進行實時監(jiān)控,并根據(jù)經(jīng)驗設(shè)定一些規(guī)則,通過將實時監(jiān)控的數(shù)據(jù)與規(guī)則進行對比,當(dāng)某個指標監(jiān)控值不符合設(shè)定的規(guī)則時,則判定為異常的狀況,這樣的話就會發(fā)送對應(yīng)的告警到告警平臺。告警平臺收到通知后,會分配給對應(yīng)的運維人員進行處理,運維人員去根據(jù)告警信息來排查,最終定位故障的根本原因,并對故障進行修復(fù)。從這個流程可以看出,整個過程是以告警為中心,所以告警的質(zhì)量是至關(guān)重要的。
但在實際運維過程中,我們可以發(fā)現(xiàn)這個過程中其實存在很多問題。首先,監(jiān)控系統(tǒng)的規(guī)則難以設(shè)定。因為規(guī)則是基于專家經(jīng)驗設(shè)定的,隨著系統(tǒng)規(guī)模變大,復(fù)雜度提高,監(jiān)控覆蓋的完善,監(jiān)控指標數(shù)量指數(shù)性增加,指標形態(tài)千變?nèi)f化,基于專家經(jīng)驗的規(guī)則設(shè)定力不從心,誤報率、漏報率居高不下。運維人員可能會遭遇告警風(fēng)暴,每天被數(shù)千個告警轟炸,難以應(yīng)付。故障發(fā)生后,對若干個告警逐一排查找故障根因,效率極低,大大增加故障的恢復(fù)時間。故障有可能無法預(yù)知,有些本來可以避免的故障還是發(fā)生了。
智能化告警的理念和相關(guān)技術(shù)
為了解決上述問題,在智能運維領(lǐng)域,智能化告警的概念出現(xiàn)了。智能化告警主要解決 4 個問題：一、精準告警,拒絕告警風(fēng)暴；二、快速故障定位；三、進行故障預(yù)測,避免故障發(fā)生；四、規(guī)則設(shè)置自動化,不再通過人工經(jīng)驗來設(shè)置規(guī)則。
智能異常檢測的核心理念是利用機器學(xué)習(xí)算法,對歷史數(shù)據(jù)的規(guī)律自動學(xué)習(xí),從而實現(xiàn)規(guī)則設(shè)置自動化。這樣的話,就不再需要人工設(shè)置大量的規(guī)則,絕大部分情況下自動學(xué)習(xí)的規(guī)則會更加準確合理,大大提高告警產(chǎn)生的質(zhì)量。
智能異常檢測的技術(shù)有指標異常檢測、日志異常檢測、根因分析和故障預(yù)測。指標異常檢測一般分為單指標異常檢測和多指標異常檢測。單指標異常檢測即時間序列異常檢測,算法分為基于統(tǒng)計的算法、無監(jiān)督學(xué)習(xí)算法和有監(jiān)督分類算法三類?；诮y(tǒng)計的算法非常簡單和容易實現(xiàn),但只能處理簡單場景。常用的無監(jiān)督學(xué)習(xí)算法有 IForest 孤立森林、LOF 局部異常因子、One-Class-SVM 、Autoencoder 自編碼器等,這類算法無需打標數(shù)據(jù),準確度比較高,但特征選取難。有監(jiān)督分類的常用算法有 XGBoost 、GBDT 、決策樹、支持向量機,這類算法非常準確,但是打標數(shù)據(jù)難以得到。多指標異常檢測即綜合多個指標判斷異常,需要先將數(shù)據(jù)降維,再使用有監(jiān)督分類和無監(jiān)督學(xué)習(xí)這兩類檢測算法。
日志是系統(tǒng)中信息頗為豐富的半結(jié)構(gòu)化數(shù)據(jù),采用日志異常檢測,可以識別系統(tǒng)實時日志中的異常,有利于問題發(fā)現(xiàn)和定位。日志檢測使用的方法有自然語言處理和日志模式識別。自然語言處理時文本向量化+深度學(xué)習(xí),理解日志中的文本信息,可識別潛在異常,結(jié)合人工反饋、標注,不斷進行模型完善和優(yōu)化。日志模式識別是對正常日志的模式進行提取,對有別于正常模式的日志進行發(fā)現(xiàn),結(jié)合特征工程,對模式匹配結(jié)果不斷進行自學(xué)習(xí)和調(diào)整。
根因分析的核心理念是利用數(shù)據(jù)挖掘算法挖掘出指標之間的相互影響關(guān)系,當(dāng)有關(guān)聯(lián)的指標同時產(chǎn)生告警,則認為影響告警側(cè)的告警為根因告警,被影響的告警為衍生告警,運維人員收到的告警只是根因告警,這樣只需排查根因告警就可以確定故障的根因,極大提高故障根因定位的效率。根因分析可以極大縮短故障根因定位時間和故障恢復(fù)時間,減少故障帶來的損失。
根因分析可以分析指標間的影響關(guān)系。利用 Pearson correlation,Spearman correlation,Kendall correlation,J-measure,Two-sample test 算法,可以進行聯(lián)動分析,判斷多個指標是否經(jīng)常一起波動或增長。利用 FP-Growth,Apriori 算法,關(guān)聯(lián)歷史上經(jīng)常一起發(fā)生的事件,進行頻繁項分析。下鉆分析,利用關(guān)聯(lián)關(guān)系匹配,尋找根因。
故障預(yù)測的核心理念是利用算法學(xué)習(xí)指標歷史的變化規(guī)律,并根據(jù)規(guī)律預(yù)測指標將來的變化趨勢,對有可能發(fā)生故障的情況提前發(fā)出告警。對未來的故障進行預(yù)測,運維人員可以提前介入,避免故障的發(fā)生,減少不必要的損失。
故障預(yù)測的方法有很多種,但主要分為三類：傳統(tǒng)統(tǒng)計方法、機器學(xué)習(xí)算法和深度學(xué)習(xí)算法。傳統(tǒng)統(tǒng)計方法有 ARIMA 、Holt-Winters 、Prophet 等,適用于預(yù)測穩(wěn)態(tài)或差分穩(wěn)態(tài)指標。機器學(xué)習(xí)算法有 XGBoost 、GBDT 等,采用特征工程根據(jù)場景構(gòu)造輸入特征,適用于預(yù)測多變量指標。深度學(xué)習(xí)算法有 RNN 循環(huán)神經(jīng)網(wǎng)絡(luò)、LSTM 長短期記憶網(wǎng)絡(luò)等,采用歷史數(shù)據(jù)滑窗方式,將預(yù)測問題轉(zhuǎn)化為監(jiān)督學(xué)習(xí)問題,使用神經(jīng)網(wǎng)絡(luò)提取特征,這類算法在絕大多數(shù)指標上都表現(xiàn)的非常好,準確率很高,但因為計算量大,對資源要求相對比較高,性能較差。
智能化告警實踐
基于以上智能告警的理念和相關(guān)方法,結(jié)合過往的實踐,我們將介紹一下在單指標異常檢測、根因分析和故障預(yù)測方面的實戰(zhàn)方案。
這張圖片展示的是單指標異常檢測的整體框架圖,主要包括離線模塊和在線模塊兩個方面。離線模塊主要是對歷史數(shù)據(jù)的學(xué)習(xí)和分析。我們在大量的實驗過程中發(fā)現(xiàn),難以找到一種就是萬能的異常檢測算法對所有指標都表現(xiàn)的比較好,某種算法通常只對特定形態(tài)的指標表現(xiàn)較好,所以我們首先對指標進行分類操作。分類之后,我們可以確定每個指標分別對應(yīng)使用的算法。接下來就可以進行算法模型參數(shù)的訓(xùn)練,將樣本庫的數(shù)據(jù)作為測試數(shù)據(jù),對模型進行評估。離線模塊是一個定時任務(wù),可以定時對某個指標重新進行分類和模型訓(xùn)練,保證模型的時效性和準確性。
在線模塊主要是利用離線模塊訓(xùn)練好的模型,對實時產(chǎn)生的監(jiān)控數(shù)據(jù)進行檢測。判斷指標的健康狀況期,主要步驟就是以實時監(jiān)控數(shù)據(jù)為模型輸入,判斷指標是否異常,如果異常的話就進行相應(yīng)的告警。此外,對模型輸出的異常提供了一個人工審核的過程,這樣的話審核的結(jié)果就保存到樣本庫中。
我們對大量的指標進行具體分析后,發(fā)現(xiàn)所有的指標都可以近似分為三大類。第一類是周期分量,這類指標有明顯的波動周期。第二類是趨勢分量,變化比較平緩,一般緩緩升高或降低,比如磁盤使用量這種指標。第三類是穩(wěn)定分量,往往只在一個區(qū)間波動,比如服務(wù)詳細時間這種指標。數(shù)據(jù)分解也是將數(shù)據(jù)分解成這三個分量。
受此啟發(fā),我們首先對時序數(shù)據(jù)進行了分解,之后可以把一個指標分解成趨勢分量、周期分量以及穩(wěn)定分量。然后分別計算這三個分量與原始曲線的一個皮爾遜相關(guān)系數(shù),系數(shù)最大的哪個分量就是指標的類別。
完成分類指標后,就可以確定用什么算法進行檢測。為了保證可靠性,我們給每種類型的指標都提供了兩種算法,并進行投票決策。對于周期性指標我們提供同比算法和基于預(yù)測的異常檢測算法；對于趨勢性指標我們使用環(huán)比算法和孤立森林算法；對于穩(wěn)定性指標我們使用 3-sigma 算法和四分位數(shù)算法。算法參數(shù)訓(xùn)練使用指標過去 7 天的歷史數(shù)據(jù),模型參數(shù)的選取采用網(wǎng)絡(luò)搜索方式確定。
這張圖展示的是根因分析的主要流程。在關(guān)聯(lián)關(guān)系分析方面,我們提供了三種方式：強關(guān)聯(lián)分析、頻繁項挖掘和相關(guān)性分析。通過這三種方法得到指標的關(guān)聯(lián)關(guān)系,有的指標關(guān)聯(lián)關(guān)鍵后,就可以對告警進行根因分析。首先將各個監(jiān)控系統(tǒng)的告警統(tǒng)一接入到我們系統(tǒng)中,并做格式統(tǒng)一處理。利用高級壓縮的一些方法,將一些無效的告警過濾掉,有效的告警進入根因分析環(huán)節(jié),得出根因分析報告,運維人員根據(jù)這個報告定位問題。
離線部分的數(shù)據(jù)來源是指標的歷史數(shù)據(jù),輸出為模型；在線部分根據(jù)模型進行計算后得到預(yù)測數(shù)據(jù),作為故障預(yù)測的數(shù)據(jù)基礎(chǔ)。由于 LSTM （長短期記憶網(wǎng)絡(luò)）能很好抓住實踐序列上下文可能存在的聯(lián)系的特性,在絕大部分情況下效果都很好,因此算法選擇方面,我們選擇 LSTM 算法作為預(yù)測模型。
這是一個故障預(yù)測的效果圖,指標是一個 Web 系統(tǒng)的訪問量,藍線代表實際值,黃線代表預(yù)測者。紅點是我們預(yù)測 Web 訪問量在這個時間點可能會達到系統(tǒng)所能承載的最大的訪問量。因此,我們可以提前發(fā)出通知,這樣運維人員可以提前進行資源增加或擴容等操作,來防止訪問量太大導(dǎo)致的服務(wù)質(zhì)量下降。
總結(jié)
發(fā)現(xiàn)故障是整個告警質(zhì)量的決定性環(huán)節(jié),所以智能異常檢測要引入更多更優(yōu)的算法,將誤報率和漏報率控制在 1% 以內(nèi)。在故障定位環(huán)節(jié),如何根據(jù)已有的數(shù)據(jù)分析出更加全面的關(guān)聯(lián)關(guān)系是重點,結(jié)合多維下鉆分析,給出更精確的故障根因。解決故障環(huán)節(jié)可以引入故障自愈,實現(xiàn)定位到問題后,自動修復(fù),進一步提高運維自動化。
點擊觀看完整課程視頻

我之前用 protonmail 注冊了一個 Facebook 賬號,注冊后我設(shè)定了頭像和姓名,然后我寫了個說說,然后幾天后登陸需要人臉認證,還要審核,我上傳后再次登陸后就封了。誰有像我樣的經(jīng)理,求原因,謝謝！

沒有發(fā)違反推特規(guī)則
http://139.224.233.92/1.jpeg
鍵政號玩了幾天漲了 1000+fo 莫名其妙凍結(jié)了,1000+fo 沒了,不能做任何操作。 提交工單幫助客服郵件什么都不回復(fù)一個月了 這是不是被“民主了”
有沒有屌大的懂解凍 唯一一張比較出格的圖片： http://139.224.233.92/2.jpeg

請問 Twitter 有辦法批量取消關(guān)注未 follow 我的人嗎follow 加到 5000 多就被限制 follow 了,現(xiàn)在懶的手動取消． ． ．

在 Twitter 上,經(jīng)常會看到類似上圖這樣使用編號 id 的賬號,雖然名字、簡介、推文看上去都挺正常,但總讓我感覺是水軍,所以我看到 id 就 block,不管他說什么??
我想問一下這種 id 是怎么來的？可以直接認為是水軍嗎？

早上起床看國聯(lián)外卡,順便刷刷推特,發(fā)現(xiàn) tweetdeck 登不進去,一直跳轉(zhuǎn)mobile.twitter.com 。下午短暫恢復(fù)了一段時間,現(xiàn)在又登不進去了。twitter 網(wǎng)頁的廣告太多,又不想用第三方客戶端,只有 tweetdeck 可以用了,twitter 在搞毛。。

為什么大部分的推文底下就有翻譯按鈕,而個別的推文下面沒有翻譯選項呢？特別是有的小語種,沒有翻譯簡直…

中文圈那種微博風(fēng)格的我實在感覺沒啥意思 不是發(fā)吃的自拍就是撩妹抖精靈或者無聊的雞湯段子

https://twitter.com/sharekuma_/status/1096226903713697793
像上面這個鏈接,不是轉(zhuǎn)發(fā)也不是引用,而是里面無框套了一層。 這是什么結(jié)構(gòu)？這個結(jié)構(gòu)的英文怎么說？有沒有辦法快速跳到原貼？

若干月前在 Twitter 上誤設(shè)置了“將你發(fā)布的媒體內(nèi)容標記為可能包含敏感內(nèi)容”,導(dǎo)致使用蘋果的小伙伴看不到我推文的圖片。如今想改回來,但發(fā)現(xiàn)只能將新發(fā)布的推文設(shè)置為非敏感內(nèi)容。請問有什么方法可以將之前發(fā)布的（或所有的）、標記為敏感的內(nèi)容取消敏感標記？（發(fā)布的內(nèi)容均為非敏感內(nèi)容）

受夠了被貼標簽,受夠了審查和禁言,現(xiàn)在只想找一個地方暢所欲言。本人目前在國內(nèi)做 DevOps,推特的日常內(nèi)容會偏向科技和時事的吐槽,歡迎互 fo。 ID: @ tacehtoel 傳送門： https://twitter.com/tacehtoel

今天突然在電腦上用 edge 裸進了中文維基的手機版（山東電信),而且速度很好,只是不能進首頁,只能 https://zh.m.wikipedia.org/wiki/搜索內(nèi)容 。
或者在在某一詞條網(wǎng)頁里的搜索欄里進行搜索。但不很穩(wěn)定,重啟瀏覽器后會打不開,只能再次重啟瀏覽器。
然后,幾分鐘后,手機和電腦上的 chrome 都成功裸進中文版,首頁也都能打開。 重要的是速度非常好！
這是怎么回事？我有點高興。

之前在一個服務(wù)器上部署了 mediawiki,在尋找模板的時候出現(xiàn)了一些問題。 由于我是初識這個 wiki 程序,按照 MediaWiki 的說法,模板沒有管理中心,想要導(dǎo)出就得用 Special:Export 然后在自己的站點上導(dǎo)入。每個 mediawiki 站點的模板都有些許不同,google 了一下也沒發(fā)現(xiàn)提供模板的網(wǎng)站。飛機 wiki 上的 workshop 倒是可以方便地看到不同的人制作的模板,但是這些模板僅限于站點之內(nèi)。除了導(dǎo)入之后自己慢慢改真的沒有其他方法了嗎？

https://zh.wikipedia.org/wiki/WP:100W
2018 年 4 月 13 日,中文維基百科條目數(shù)達到 1,000,000 條。目前的第一百萬條條目是：已分配的 /8 IPv4 地址塊列表（ https://zh.m.wikipedia.org/wiki/%E5%B7%B2%E5%88%86%E9%85%8D%E7%9A%84/8_IPv4%E5%9C%B0%E5%9D%80%E5%9D%97%E5%88%97%E8%A1%A8 ）。

維基百科在這里收集了各種關(guān)于電腦、移動設(shè)備、游戲的列表的名錄,V2er 們都可以找到自己熟悉的東西。https://en.wikipedia.org/wiki/Category:Electronics_lists

喜歡開源軟件的 V 友們都可以進來瞧一瞧,總有一款適合你。https://en.wikipedia.org/wiki/List_of_free_and_open-source_software_packages

目前多個 iOS 軟件因此閃退,上個月已經(jīng)發(fā)生過一次了。聽歌聽不了很惱人（目前可以通過飛行模式打開軟件）
9to5mac.com/2020/07/10/app-crash-facebook-sdk/

lz 是個人開發(fā)者,Facebook 廣告賬戶是自己申請注冊的,投放的廣告一直都是本本分分,沒有任何違規(guī)的,只要我在 Facebook 商品主頁上發(fā)布一條消息,不管什么消息,都會把我賬號給封禁掉。每次申請解封,都是過一天左右解封。我始終都不知道觸發(fā)了 Facebook 的什么機制。我是綁定國內(nèi)信用卡支付廣告費的,現(xiàn)在沒幾天一結(jié)算的時候,就會把我賬號封禁,然后又是申訴恢復(fù)。之前有過很長一段時間,只要付款就會被封禁。
現(xiàn)在的封禁是直接封禁,連封禁消息郵件都沒有,搞得挺蛋疼的,VPN 用的是付費的,一個節(jié)點常年使用,瀏覽器也是專門的瀏覽器,不在其他地方登陸 Facebook 相關(guān)賬戶。
被封了幾十次,自始至終都不知道到底違反了什么規(guī)則,這是最尷尬的～
lz 除了是個運營推廣苦手,花著幾倍的成本去投放廣告外,老老實實掏錢,真的啥都沒干
現(xiàn)在問題來了： 這種封禁怎么規(guī)避哈 lz 是個人開發(fā)者,每個月的廣告推廣費差不多兩三千塊錢,有沒有小的渠道可以帶投廣告,lz 實在無暇去 cover 運營相關(guān)事宜
萬分感謝,祝暴富～

我已經(jīng)注冊了好多的個 fb,總被封。使用手機解封后又不成功,需要上傳照片。 注冊了的但沒使用的發(fā)送的郵件多得不得了 ‘come there to meet your new friends??’ 唉!

之前一直使用支付寶充值,一個星期前,一張?zhí)摂M信用卡里面有 500 多塊錢,就想著用掉,用這張卡去充值,然而悲劇了,提示賬號異常,阻止了充值,并把廣告賬戶給停了,申訴了過后,當(dāng)天就解禁了,后面反反復(fù)復(fù)用了七八次支付寶,個人信用卡充值,都是提示異常,然后把廣告賬號給停了。
這種情況該如何處理啊,各位大佬,我現(xiàn)在無法充值了,給 Facebook 發(fā)送反饋啥的,都是機器回復(fù),好蛋疼呀。
一充值就提示這個。
由于帳戶存在異?；顒?你的支付功能已暫停。

很早之前郵箱注冊的賬號,前段時間被封了,上傳照片也沒用,前幾天嘗試用 google voice 又重新注冊了一個,結(jié)果用了 1 天,又提示上傳照片,上傳完又被封了,這是逼我不要用嘛,看來是得教教海外同事用微信了~
誰賬號可用的麻煩墻外幫我看下我的 facebook 主頁是否正常,ID：realChengYong

賬戶被凍結(jié),要安全驗證,點下一步驗證就是無法驗證,不提供任何途徑驗證。 這個賬戶大概凍結(jié)兩年多了,當(dāng)時是 163 郵箱沒法驗證,導(dǎo)致沒法解凍?，F(xiàn)在完全不給驗證途徑了,但是沒事還給我郵箱里發(fā)一些賬戶信息,昨天試了下還能通過 163 郵箱改密碼,就是不給我解凍,什么鬼設(shè)定啊。另外這幾天 twitter 也給我鎖了,我基本不說話的,不涉及任何政治敏感詞,也沒罵人。最后幾條消息就是我分享的 fivefilters 和 sololearn 的鏈接。我懷疑我的倆賬戶都是因為換 VPN 給鎖的,這玩意對國內(nèi)體驗真是太不好了。 [img] https://i.loli.net/2019/05/07/5cd0d2d0036e0.png [/img] [img] https://i.loli.net/2019/05/07/5cd0d2d011e9c.png [/img]

手賤在 pbug 里綁定了微信賬號,pbug 是用 Facebook 登錄的 請問大佬們,Facebook 在第三方登錄的時候會不會把郵箱之類的泄露給騰訊 要是泄漏了只能注銷了 Facebook 了 微信不放心用

一直都用的好好的,前天說要上傳一張頭像,上傳了之后,第二天,就提示賬號停用了,請問有什么辦法可以解決.

已經(jīng)科學(xué)的訪問 reddit,但是網(wǎng)站還是打不開,hackernews 也是,請問是什么原因呢？

請加入我們的“ App_Store ”社區(qū)并開始訂閱 RSS。 社區(qū)鏈接： https://www.reddit.com/r/App_Store RSS 鏈接： http://www.reddit.com/r/App_Store.rss

發(fā)帖后 100%都會收到消息： https://imgup.nl/images/2019/05/05/QQ20190505-170435.jpg
又看不懂到底說了啥。叫我看規(guī)則,規(guī)則打開一堆東西我咋知道具體怎么回事呢？

Reddit experiencing a site outage"Reddit can't be reached," the popular news discussion site says. https://www.cnet.com/news/reddit-experiencing-a-site-outage/