最新章節

• 文后
• 內容簡介
• 參考文獻
• 8.7.4 借助開源社區的力量幫助企業IT云在模糊中安全前行
• 8.7.3 借助開源社區的力量幫助企業掌控開源軟件的復雜度
• 8.7.2 借助開源社區的力量讓全球技術發展的不確定性變得相對確定

• 文后 更新時間：2024-04-15 11:53:12
• 內容簡介
• 參考文獻
• 8.7.4 借助開源社區的力量幫助企業IT云在模糊中安全前行
• 8.7.3 借助開源社區的力量幫助企業掌控開源軟件的復雜度
• 8.7.2 借助開源社區的力量讓全球技術發展的不確定性變得相對確定
• 8.7.1 借助開源社區和開源軟件幫助從業者應對技術發展的不穩定性
• 8.7 開源是企業在烏卡時代的不二選擇
• 8.6.3 借助開源社區主流企業的力量，提前進行技術儲備
• 8.6.2 有條件的企業可以積極投入技術力量參與開源軟件的研發和決策
• 8.6.1 合理界定開源軟件和企業應用/平臺之間的功能分界
• 8.6 企業開源自研道路的未來
• 8.5.4 借助開源技術人才體系創造雙贏
• 8.5.3 開源技術梯隊化的配置和開源技術人才生態圈
• 8.5.2 多樣化的開源軟件人才團隊
• 8.5.1 強有力的團隊領導者
• 8.5 構建開源技術人才建設體系
• 8.4.3 開源軟件的服務模式和行業特性
• 8.4.2 企業版開源軟件的合規
• 8.4.1 開源軟件的協議/許可證風險
• 8.4 企業開源軟件的合規和風險管理
• 8.3.4 加速創新和業務增長
• 8.3.3 協作與社區共同創新
• 8.3.2 生態的共存和發展的意義
• 8.3.1 遵循“上游優先”的原則
• 8.3 企業開源要實現共贏
• 8.2 企業開源需要能夠淘汰自我
• 8.1.2 企業開源響應國家政策
• 8.1.1 IT新常態始于開源
• 8.1 企業開源需要順應時代策略
• 第8章 企業開源實踐的未來與展望
• 7.8 展望
• 7.7 開放創新工作坊創造超越技術的收益
• 7.6.9 開放實踐庫
• 7.6.8 KISS模型保障團隊反饋效果
• 7.6.7 里程碑圖
• 7.6.6 事件風暴模型
• 7.6.5 同理心地圖
• 7.6.4 平衡輪
• 7.6.3 領域驅動設計
• 7.6.2 影響力地圖
• 7.6.1 商業模式畫布
• 7.6 開放創新工作坊的團隊共創模型
• 7.5.5 在線開放創新工作坊的工具
• 7.5.4 在線開放創新工作坊的收官
• 7.5.3 如何交付在線開放創新工作坊
• 7.5.2 如何準備在線開放創新工作坊
• 7.5.1 時代催生在線開放創新工作坊的新玩法
• 7.5 在線開展開放創新工作坊
• 7.4.5 規模化容器云平臺建設工作坊
• 7.4.4 保險行業自動化平臺建設規劃工作坊
• 7.4.3 金融行業云廠商云平臺建設工作坊
• 7.4.2 制造業中臺工作坊
• 7.4.1 銀行業DevOps平臺工作坊
• 7.4 特定領域的開放創新工作坊實踐
• 7.3.3 開放創新工作坊的收官
• 7.3.2 如何執行開放創新工作坊
• 7.3.1 如何準備開放創新工作坊
• 7.3 如何交付開放創新工作坊
• 7.2.4 開放創新工作坊的價值
• 7.2.3 開放創新工作坊與傳統會議
• 7.2.2 開放創新工作坊的工作目標
• 7.2.1 開放創新工作坊的定義
• 7.2 來自社區的開放創新工作坊
• 7.1.3 開源社區為企業軟件開發設立“新模式”
• 7.1.2 企業軟件開發過程正在快速整合
• 7.1.1 烏卡時代，集中式軟件開發工作挑戰多多
• 7.1 容器云給軟件開發帶來的模式變革
• 第7章 開放創新工作坊實踐之旅
• 6.7 本章小結
• 6.6.4 ACS云原生安全產品的價值
• 6.6.3 ACS從預前檢測、運行保護、事中響應三個階段完善容器安全管理
• 6.6.2 ACS云原生安全平臺的技術特點
• 6.6.1 紅帽ACS解決云原生安全問題的6個集中式安全管理策略
• 6.6 紅帽ACS采用云原生方式解決云原生安全問題
• 6.5.4 交易所行業通過ACS實現容器平臺安全管理
• 6.5.3 服務行業客戶采用紅帽3Scale平臺構建開放API管理平臺
• 6.5.2 金融行業企業借助網絡策略實現統一集群內關鍵應用的隔離
• 6.5.1 ACS支持公有云用戶構建容器云平臺安全防線
• 6.5 紅帽關于企業云原生安全的實踐經驗總結
• 6.4.4 國內的安全規范
• 6.4.3 PCI DSS
• 6.4.2 美國國家標準與技術研究院發布的容器安全指南
• 6.4.1 Docker和Kubernetes的CIS基準
• 6.4 云原生時代容器技術安全標準
• 6.3.10 集中化安全管理的框架
• 6.3.9 全方位看待容器安全管理
• 6.3.8 云原生安全策略化
• 6.3.7 安全代碼化
• 6.3.6 安全左移
• 6.3.5 容器技術安全
• 6.3.4 Kubernetes云原生安全的6個關鍵標準
• 6.3.3 云原生安全的4C
• 6.3.2 Kubernetes原生安全
• 6.3.1 容器安全的3種構建思路
• 6.3 如何構建企業級云原生容器安全管理體系
• 6.2.2 企業云原生時代安全技術的快速發展
• 6.2.1 企業使用云原生容器技術時面臨的12個挑戰
• 6.2 企業為什么要關注云原生安全
• 6.1.2 云原生時代的企業信息安全
• 6.1.1 安全技術的發展歷程
• 6.1 從傳統云安全到云原生安全
• 第6章 企業云原生安全實踐之旅
• 5.8 本章小結
• 5.7 利用規模化企業級容器云平臺管理框架提升數據中心整體效能
• 5.6.7 混合云的容器平臺需要搭配跨職能混合云平臺團隊
• 5.6.6 OpenShift和IPaaS集成云平臺
• 5.6.5 銀行業正在積極嘗試容器化數據中心
• 5.6.4 大型生產企業基于OpenShift構建統一云平臺
• 5.6.3 國內銀行借助OpenShift快速跨越上萬容器
• 5.6.2 國際大型金融集團更青睞OpenShift企業版
• 5.6.1 保險行業選擇OpenShift規避自研Kubernetes平臺的投入陷阱
• 5.6 紅帽關于企業容器化的實踐經驗總結
• 5.5.5 規模化容器平臺打開企業算力的關鍵
• 5.5.4 構建企業級容器云平臺的5大場景
• 5.5.3 企業容器化運行管理框架未來全景概覽
• 5.5.2 企業容器化運行管理框架
• 5.5.1 從原始需求構建容器云平臺——圍繞服務進行設計
• 5.5 企業容器化之解決方案
• 5.4.4 活躍技術生態——緊跟社區
• 5.4.3 全方位安全——策略化安全
• 5.4.2 運維能力升級——自管理
• 5.4.1 開發友好性——自服務
• 5.4 企業容器化之應對策略
• 5.3.4 企業容器規模化擴張與整體高可用性挑戰
• 5.3.3 企業容器規模化擴張面臨的技術挑戰
• 5.3.2 企業容器規模化擴張面臨的管理挑戰
• 5.3.1 企業容器規模化擴張之路是不連續的
• 5.3 企業容器化之新的挑戰
• 5.2.4 構建穩定的容器云建設團隊
• 5.2.3 企業容器化和社區平臺發展的關系
• 5.2.2 企業容器化數據中心的建設
• 5.2.1 企業容器化的建設和發展階段
• 5.2 企業容器化之旅
• 5.1.4 小結
• 5.1.3 企業容器化發展方向
• 5.1.2 社區容器云平臺發展的路徑和未來方向
• 5.1.1 企業運用容器技術的幾種典型方式
• 5.1 企業容器化的方式和典型趨勢
• 第5章 企業容器化實踐之旅
• 4.10 本章小結
• 4.9 開源文化
• 4.8.2 開源治理認證
• 4.8.1 紅帽的開源軟件成熟度模型
• 4.8 開源治理成熟度模型和認證
• 4.7.3 金融行業借助現有架構師團隊快速落地開源治理
• 4.7.2 證券行業客戶通過六大領域快速提升開源治理能力
• 4.7.1 保險行業推進開源軟件治理
• 4.7 開源軟件治理實踐經驗總結
• 4.6.6 關鍵任務6——開源軟件管理平臺
• 4.6.5 關鍵任務5——開源軟件創新實驗室
• 4.6.4 關鍵任務4——開源技術管理委員會
• 4.6.3 關鍵任務3——開源軟件生命周期管理
• 4.6.2 關鍵任務2——開源軟件管理制度
• 4.6.1 關鍵任務1——開源技術庫
• 4.6 企業開源治理的6個關鍵任務
• 4.5.5 開源軟件評估模型的角色分工
• 4.5.4 開源軟件評估模型的設計
• 4.5.3 開源軟件成熟度模型的基本框架
• 4.5.2 從開源軟件使用的4個場景出發構建開源軟件評估模型
• 4.5.1 為什么要建立開源軟件評估模型
• 4.5 企業開源軟件治理的1個核心：開源軟件評估模型
• 4.4.4 開源軟件治理框架Culture——文化建設
• 4.4.3 開源軟件治理框架Technology——技術和工具
• 4.4.2 開源軟件治理框架Progress——建立流程
• 4.4.1 開源軟件治理框架People——建立團隊和開源治理組織
• 4.4 開源軟件治理框架的4個維度：PPTC
• 4.3 企業如何有效管理開源軟件
• 4.2.4 開源軟件的管理需要擁抱創新、防范風險
• 4.2.3 開源軟件的大規模使用給企業帶來了全新的問題和挑戰
• 4.2.2 開源軟件具備非常明顯的優勢
• 4.2.1 開源軟件已經滲入企業IT環境的各個領域
• 4.2 為什么需要管理開源軟件
• 4.1 開源是共識，是趨勢，是改變世界的力量
• 第4章 企業開源治理實踐之旅
• 3.6 本章小結
• 3.5.3 混合云基礎架構的相關實踐
• 3.5.2 采用混沌工程的相關實踐
• 3.5.1 不可變基礎架構的相關實踐
• 3.5 紅帽關于云原生基礎架構的實踐
• 3.4.5 小結
• 3.4.4 構建異構、開放的混合云架構
• 3.4.3 構建具有韌性的基礎架構
• 3.4.2 構建能夠持續迭代的基礎架構
• 3.4.1 構建不可變的基礎架構
• 3.4 云原生基礎架構的構建思路
• 3.3.4 對云原生基礎架構定義的共識
• 3.3.3 對云原生基礎架構的誤解
• 3.3.2 云原生基礎架構的核心特征
• 3.3.1 云原生基礎架構的定義
• 3.3 云原生基礎架構的定義和核心特征
• 3.2.6 企業需要面對邊緣端基礎架構的挑戰
• 3.2.5 企業上云后的窘境
• 3.2.4 基礎架構團隊的技能和改變問題
• 3.2.3 應用形態的多樣化和交付格式的標準化
• 3.2.2 基礎架構的運維需要更加行之有效的方式
• 3.2.1 應用需求爆發式增長，需要選擇更加合適的基礎設施
• 3.2 云原生基礎架構的現實意義
• 3.1.8 趨勢總結
• 3.1.7 Kubernetes的云原生架構是目前的最優解
• 3.1.6 兩化融合和云邊協同
• 3.1.5 算力的需求是云計算要解決的核心問題
• 3.1.4 階段四——應用定義基礎架構
• 3.1.3 階段三——超融合的基礎架構以及軟件定義數據中心
• 3.1.2 階段二——x86虛擬化
• 3.1.1 階段一——從小型機到裸機服務器
• 3.1 企業基礎架構的演進和趨勢分析
• 第3章 企業云原生基礎架構實踐之旅
• 2.6 本章小結
• 2.5 企業云原生應用的未來發展趨勢
• 2.4.5 通過紅帽開放創新實驗室提升企業團隊能力
• 2.4.4 通過紅帽OpenShift提供企業云原生平臺服務
• 2.4.3 通過紅帽微服務旅程實現應用架構改造
• 2.4.2 通過紅帽賦能實現企業應用現代化
• 2.4.1 紅帽關于云原生應用的構建思路
• 2.4 紅帽關于云原生應用的構建思路和相關實踐
• 2.3.5 對于云原生應用的共識
• 2.3.4 組織架構需要的改變
• 2.3.3 運維模式需要的改變
• 2.3.2 開發方式帶來的挑戰和變化
• 2.3.1 軟件架構沒有變化
• 2.3 云原生應用的挑戰和誤解
• 2.2.4 云原生應用的關注點分離
• 2.2.3 云原生應用的模型
• 2.2.2 云原生應用的核心原則
• 2.2.1 云原生應用的定義
• 2.2 云原生應用的定義和核心原則
• 2.1.8 云原生應用適配數據驅動的業務
• 2.1.7 云原生應用適配多元算力的發展
• 2.1.6 云原生應用縮短創新反饋周期
• 2.1.5 云原生應用助力企業戰略規劃
• 2.1.4 云原生應用助力業務的穩定性
• 2.1.3 云原生應用提升用戶的最終體驗
• 2.1.2 云原生應用加速企業敏捷創新
• 2.1.1 云原生應用帶來新的業務交付模式
• 2.1 云原生應用是企業應用發展的核心
• 第2章 企業云原生應用實踐之旅
• 1.5.6 開放創新工作坊
• 1.5.5 開源治理
• 1.5.4 開源安全
• 1.5.3 容器
• 1.5.2 云原生基礎架構
• 1.5.1 云原生應用
• 1.5 企業開源實踐和能力建設
• 1.4.5 云原生
• 1.4.4 基礎設施
• 1.4.3 系統
• 1.4.2 框架
• 1.4.1 組件
• 1.4 開源軟件重塑企業IT架構
• 1.3.4 開源軟件的供應鏈
• 1.3.3 企業版/社區版
• 1.3.2 開源軟件圖譜
• 1.3.1 開源軟件存在的基礎
• 1.3 認識企業開源軟件
• 1.2.4 打開算力
• 1.2.3 開源軟件匯聚全球科技成果
• 1.2.2 開源軟件成為企業創新的基礎
• 1.2.1 企業離不開云計算、開源、云原生
• 1.2 企業使用開源軟件的重要性
• 1.1.3 企業和開源的關系
• 1.1.2 什么是開源軟件
• 1.1.1 現代企業的變化
• 1.1 現代企業為什么需要開源軟件
• 第1章 開啟企業開源之旅
• 前言
• 推薦序
• 作者簡介
• 版權信息
• 封面

• 封面
• 版權信息
• 作者簡介
• 推薦序
• 前言
• 第1章 開啟企業開源之旅
• 1.1 現代企業為什么需要開源軟件
• 1.1.1 現代企業的變化
• 1.1.2 什么是開源軟件
• 1.1.3 企業和開源的關系
• 1.2 企業使用開源軟件的重要性
• 1.2.1 企業離不開云計算、開源、云原生
• 1.2.2 開源軟件成為企業創新的基礎
• 1.2.3 開源軟件匯聚全球科技成果
• 1.2.4 打開算力
• 1.3 認識企業開源軟件
• 1.3.1 開源軟件存在的基礎
• 1.3.2 開源軟件圖譜
• 1.3.3 企業版/社區版
• 1.3.4 開源軟件的供應鏈
• 1.4 開源軟件重塑企業IT架構
• 1.4.1 組件
• 1.4.2 框架
• 1.4.3 系統
• 1.4.4 基礎設施
• 1.4.5 云原生
• 1.5 企業開源實踐和能力建設
• 1.5.1 云原生應用
• 1.5.2 云原生基礎架構
• 1.5.3 容器
• 1.5.4 開源安全
• 1.5.5 開源治理
• 1.5.6 開放創新工作坊
• 第2章 企業云原生應用實踐之旅
• 2.1 云原生應用是企業應用發展的核心
• 2.1.1 云原生應用帶來新的業務交付模式
• 2.1.2 云原生應用加速企業敏捷創新
• 2.1.3 云原生應用提升用戶的最終體驗
• 2.1.4 云原生應用助力業務的穩定性
• 2.1.5 云原生應用助力企業戰略規劃
• 2.1.6 云原生應用縮短創新反饋周期
• 2.1.7 云原生應用適配多元算力的發展
• 2.1.8 云原生應用適配數據驅動的業務
• 2.2 云原生應用的定義和核心原則
• 2.2.1 云原生應用的定義
• 2.2.2 云原生應用的核心原則
• 2.2.3 云原生應用的模型
• 2.2.4 云原生應用的關注點分離
• 2.3 云原生應用的挑戰和誤解
• 2.3.1 軟件架構沒有變化
• 2.3.2 開發方式帶來的挑戰和變化
• 2.3.3 運維模式需要的改變
• 2.3.4 組織架構需要的改變
• 2.3.5 對于云原生應用的共識
• 2.4 紅帽關于云原生應用的構建思路和相關實踐
• 2.4.1 紅帽關于云原生應用的構建思路
• 2.4.2 通過紅帽賦能實現企業應用現代化
• 2.4.3 通過紅帽微服務旅程實現應用架構改造
• 2.4.4 通過紅帽OpenShift提供企業云原生平臺服務
• 2.4.5 通過紅帽開放創新實驗室提升企業團隊能力
• 2.5 企業云原生應用的未來發展趨勢
• 2.6 本章小結
• 第3章 企業云原生基礎架構實踐之旅
• 3.1 企業基礎架構的演進和趨勢分析
• 3.1.1 階段一——從小型機到裸機服務器
• 3.1.2 階段二——x86虛擬化
• 3.1.3 階段三——超融合的基礎架構以及軟件定義數據中心
• 3.1.4 階段四——應用定義基礎架構
• 3.1.5 算力的需求是云計算要解決的核心問題
• 3.1.6 兩化融合和云邊協同
• 3.1.7 Kubernetes的云原生架構是目前的最優解
• 3.1.8 趨勢總結
• 3.2 云原生基礎架構的現實意義
• 3.2.1 應用需求爆發式增長，需要選擇更加合適的基礎設施
• 3.2.2 基礎架構的運維需要更加行之有效的方式
• 3.2.3 應用形態的多樣化和交付格式的標準化
• 3.2.4 基礎架構團隊的技能和改變問題
• 3.2.5 企業上云后的窘境
• 3.2.6 企業需要面對邊緣端基礎架構的挑戰
• 3.3 云原生基礎架構的定義和核心特征
• 3.3.1 云原生基礎架構的定義
• 3.3.2 云原生基礎架構的核心特征
• 3.3.3 對云原生基礎架構的誤解
• 3.3.4 對云原生基礎架構定義的共識
• 3.4 云原生基礎架構的構建思路
• 3.4.1 構建不可變的基礎架構
• 3.4.2 構建能夠持續迭代的基礎架構
• 3.4.3 構建具有韌性的基礎架構
• 3.4.4 構建異構、開放的混合云架構
• 3.4.5 小結
• 3.5 紅帽關于云原生基礎架構的實踐
• 3.5.1 不可變基礎架構的相關實踐
• 3.5.2 采用混沌工程的相關實踐
• 3.5.3 混合云基礎架構的相關實踐
• 3.6 本章小結
• 第4章 企業開源治理實踐之旅
• 4.1 開源是共識，是趨勢，是改變世界的力量
• 4.2 為什么需要管理開源軟件
• 4.2.1 開源軟件已經滲入企業IT環境的各個領域
• 4.2.2 開源軟件具備非常明顯的優勢
• 4.2.3 開源軟件的大規模使用給企業帶來了全新的問題和挑戰
• 4.2.4 開源軟件的管理需要擁抱創新、防范風險
• 4.3 企業如何有效管理開源軟件
• 4.4 開源軟件治理框架的4個維度：PPTC
• 4.4.1 開源軟件治理框架People——建立團隊和開源治理組織
• 4.4.2 開源軟件治理框架Progress——建立流程
• 4.4.3 開源軟件治理框架Technology——技術和工具
• 4.4.4 開源軟件治理框架Culture——文化建設
• 4.5 企業開源軟件治理的1個核心：開源軟件評估模型
• 4.5.1 為什么要建立開源軟件評估模型
• 4.5.2 從開源軟件使用的4個場景出發構建開源軟件評估模型
• 4.5.3 開源軟件成熟度模型的基本框架
• 4.5.4 開源軟件評估模型的設計
• 4.5.5 開源軟件評估模型的角色分工
• 4.6 企業開源治理的6個關鍵任務
• 4.6.1 關鍵任務1——開源技術庫
• 4.6.2 關鍵任務2——開源軟件管理制度
• 4.6.3 關鍵任務3——開源軟件生命周期管理
• 4.6.4 關鍵任務4——開源技術管理委員會
• 4.6.5 關鍵任務5——開源軟件創新實驗室
• 4.6.6 關鍵任務6——開源軟件管理平臺
• 4.7 開源軟件治理實踐經驗總結
• 4.7.1 保險行業推進開源軟件治理
• 4.7.2 證券行業客戶通過六大領域快速提升開源治理能力
• 4.7.3 金融行業借助現有架構師團隊快速落地開源治理
• 4.8 開源治理成熟度模型和認證
• 4.8.1 紅帽的開源軟件成熟度模型
• 4.8.2 開源治理認證
• 4.9 開源文化
• 4.10 本章小結
• 第5章 企業容器化實踐之旅
• 5.1 企業容器化的方式和典型趨勢
• 5.1.1 企業運用容器技術的幾種典型方式
• 5.1.2 社區容器云平臺發展的路徑和未來方向
• 5.1.3 企業容器化發展方向
• 5.1.4 小結
• 5.2 企業容器化之旅
• 5.2.1 企業容器化的建設和發展階段
• 5.2.2 企業容器化數據中心的建設
• 5.2.3 企業容器化和社區平臺發展的關系
• 5.2.4 構建穩定的容器云建設團隊
• 5.3 企業容器化之新的挑戰
• 5.3.1 企業容器規模化擴張之路是不連續的
• 5.3.2 企業容器規模化擴張面臨的管理挑戰
• 5.3.3 企業容器規模化擴張面臨的技術挑戰
• 5.3.4 企業容器規模化擴張與整體高可用性挑戰
• 5.4 企業容器化之應對策略
• 5.4.1 開發友好性——自服務
• 5.4.2 運維能力升級——自管理
• 5.4.3 全方位安全——策略化安全
• 5.4.4 活躍技術生態——緊跟社區
• 5.5 企業容器化之解決方案
• 5.5.1 從原始需求構建容器云平臺——圍繞服務進行設計
• 5.5.2 企業容器化運行管理框架
• 5.5.3 企業容器化運行管理框架未來全景概覽
• 5.5.4 構建企業級容器云平臺的5大場景
• 5.5.5 規模化容器平臺打開企業算力的關鍵
• 5.6 紅帽關于企業容器化的實踐經驗總結
• 5.6.1 保險行業選擇OpenShift規避自研Kubernetes平臺的投入陷阱
• 5.6.2 國際大型金融集團更青睞OpenShift企業版
• 5.6.3 國內銀行借助OpenShift快速跨越上萬容器
• 5.6.4 大型生產企業基于OpenShift構建統一云平臺
• 5.6.5 銀行業正在積極嘗試容器化數據中心
• 5.6.6 OpenShift和IPaaS集成云平臺
• 5.6.7 混合云的容器平臺需要搭配跨職能混合云平臺團隊
• 5.7 利用規模化企業級容器云平臺管理框架提升數據中心整體效能
• 5.8 本章小結
• 第6章 企業云原生安全實踐之旅
• 6.1 從傳統云安全到云原生安全
• 6.1.1 安全技術的發展歷程
• 6.1.2 云原生時代的企業信息安全
• 6.2 企業為什么要關注云原生安全
• 6.2.1 企業使用云原生容器技術時面臨的12個挑戰
• 6.2.2 企業云原生時代安全技術的快速發展
• 6.3 如何構建企業級云原生容器安全管理體系
• 6.3.1 容器安全的3種構建思路
• 6.3.2 Kubernetes原生安全
• 6.3.3 云原生安全的4C
• 6.3.4 Kubernetes云原生安全的6個關鍵標準
• 6.3.5 容器技術安全
• 6.3.6 安全左移
• 6.3.7 安全代碼化
• 6.3.8 云原生安全策略化
• 6.3.9 全方位看待容器安全管理
• 6.3.10 集中化安全管理的框架
• 6.4 云原生時代容器技術安全標準
• 6.4.1 Docker和Kubernetes的CIS基準
• 6.4.2 美國國家標準與技術研究院發布的容器安全指南
• 6.4.3 PCI DSS
• 6.4.4 國內的安全規范
• 6.5 紅帽關于企業云原生安全的實踐經驗總結
• 6.5.1 ACS支持公有云用戶構建容器云平臺安全防線
• 6.5.2 金融行業企業借助網絡策略實現統一集群內關鍵應用的隔離
• 6.5.3 服務行業客戶采用紅帽3Scale平臺構建開放API管理平臺
• 6.5.4 交易所行業通過ACS實現容器平臺安全管理
• 6.6 紅帽ACS采用云原生方式解決云原生安全問題
• 6.6.1 紅帽ACS解決云原生安全問題的6個集中式安全管理策略
• 6.6.2 ACS云原生安全平臺的技術特點
• 6.6.3 ACS從預前檢測、運行保護、事中響應三個階段完善容器安全管理
• 6.6.4 ACS云原生安全產品的價值
• 6.7 本章小結
• 第7章 開放創新工作坊實踐之旅
• 7.1 容器云給軟件開發帶來的模式變革
• 7.1.1 烏卡時代，集中式軟件開發工作挑戰多多
• 7.1.2 企業軟件開發過程正在快速整合
• 7.1.3 開源社區為企業軟件開發設立“新模式”
• 7.2 來自社區的開放創新工作坊
• 7.2.1 開放創新工作坊的定義
• 7.2.2 開放創新工作坊的工作目標
• 7.2.3 開放創新工作坊與傳統會議
• 7.2.4 開放創新工作坊的價值
• 7.3 如何交付開放創新工作坊
• 7.3.1 如何準備開放創新工作坊
• 7.3.2 如何執行開放創新工作坊
• 7.3.3 開放創新工作坊的收官
• 7.4 特定領域的開放創新工作坊實踐
• 7.4.1 銀行業DevOps平臺工作坊
• 7.4.2 制造業中臺工作坊
• 7.4.3 金融行業云廠商云平臺建設工作坊
• 7.4.4 保險行業自動化平臺建設規劃工作坊
• 7.4.5 規模化容器云平臺建設工作坊
• 7.5 在線開展開放創新工作坊
• 7.5.1 時代催生在線開放創新工作坊的新玩法
• 7.5.2 如何準備在線開放創新工作坊
• 7.5.3 如何交付在線開放創新工作坊
• 7.5.4 在線開放創新工作坊的收官
• 7.5.5 在線開放創新工作坊的工具
• 7.6 開放創新工作坊的團隊共創模型
• 7.6.1 商業模式畫布
• 7.6.2 影響力地圖
• 7.6.3 領域驅動設計
• 7.6.4 平衡輪
• 7.6.5 同理心地圖
• 7.6.6 事件風暴模型
• 7.6.7 里程碑圖
• 7.6.8 KISS模型保障團隊反饋效果
• 7.6.9 開放實踐庫
• 7.7 開放創新工作坊創造超越技術的收益
• 7.8 展望
• 第8章 企業開源實踐的未來與展望
• 8.1 企業開源需要順應時代策略
• 8.1.1 IT新常態始于開源
• 8.1.2 企業開源響應國家政策
• 8.2 企業開源需要能夠淘汰自我
• 8.3 企業開源要實現共贏
• 8.3.1 遵循“上游優先”的原則
• 8.3.2 生態的共存和發展的意義
• 8.3.3 協作與社區共同創新
• 8.3.4 加速創新和業務增長
• 8.4 企業開源軟件的合規和風險管理
• 8.4.1 開源軟件的協議/許可證風險
• 8.4.2 企業版開源軟件的合規
• 8.4.3 開源軟件的服務模式和行業特性
• 8.5 構建開源技術人才建設體系
• 8.5.1 強有力的團隊領導者
• 8.5.2 多樣化的開源軟件人才團隊
• 8.5.3 開源技術梯隊化的配置和開源技術人才生態圈
• 8.5.4 借助開源技術人才體系創造雙贏
• 8.6 企業開源自研道路的未來
• 8.6.1 合理界定開源軟件和企業應用/平臺之間的功能分界
• 8.6.2 有條件的企業可以積極投入技術力量參與開源軟件的研發和決策
• 8.6.3 借助開源社區主流企業的力量，提前進行技術儲備
• 8.7 開源是企業在烏卡時代的不二選擇
• 8.7.1 借助開源社區和開源軟件幫助從業者應對技術發展的不穩定性
• 8.7.2 借助開源社區的力量讓全球技術發展的不確定性變得相對確定
• 8.7.3 借助開源社區的力量幫助企業掌控開源軟件的復雜度
• 8.7.4 借助開源社區的力量幫助企業IT云在模糊中安全前行
• 參考文獻
• 內容簡介
• 文后 更新時間：2024-04-15 11:53:12