作者： 菜, 鸟

智慧电厂一体化解决方案

  1. 智慧电厂时代，企业生产管理与目标发生改变

  1. 智慧电厂建设内容与建设目标

  1. 智慧电厂建设演进-云化、平台化、生态化

  1. 智慧电厂IT基础设施演进趋势

  1. 智慧电厂工业平台参考架构

  1. 智能工业平台支持发电企业数字化、智慧化转型

  1. 能源行业智慧平台解决方案

  1. 智慧电厂总体架构-云是基础、平台是关键、应用是核心

  1. 智慧电厂IT云化发展趋势

  1. 传统电厂IT方案与智慧电厂云方案的对比

公有云安全概述

云安全职责划分：共同担责

1、软件即服务SAAS

云服务厂家几乎负责所有的安全性，因为租户只能访问、管理和使用其提供的应用程序，但无法对应用程序做破坏性操作。例如：SAAS服务厂家提供安全、日志、运维、审计、应用安全性检测等，二租户只能给管理租户账户和权限。

2、平台及服务PAAS

云服务厂家负责平台的安全性，租户负责平台上部署的应用，包括所有的应用安全配置。两者职责几乎均分。例如RDS关系型数据库服务，云服务厂家提供RDS实例管理安全、RDS实例的修复和核心配置。租户对数据库账户、访问安全等负责。

3、基础设置即服务IAAS

云服务厂家负责基本的安全，而租户负责在此基础上搭建的其它安全。相比PAAS，IAAS租户承担更多的职责。

租户安全关注点：治理和企业风险管理

组织治理和度量云计算带来的企业风险的能力。 例如违约的判决先例，用户组织充分评估云提供商风险的能 力，当用户和提供商都有可能出现故障时保护敏感数据的责任，及国际边界对这些问题有何影响等都是关注点。

1、法律问题：合同和电子举证

使用云计算时潜在的法律问题。 本节涉及的的问题包括信息和计算机系统的保护要求、安全漏 洞信息披露的法律、监管要求，隐私要求和国际法等。

2、合规性和审计管理

保持和证明使用云计算的合规性。 本节涉及评估云计算如何影响内部安全策略的合规性、以及不同的合规性要求（规章、法规等）。同时还提供在审计过程中 证明合规性的一些指导。

3、信息治理

治理云中的数据。 本节涉及云中数据的识别和控制；以及可用于处理数据迁移到 云中时失去物理控制这一问题的补偿控制。也提及其它项，如谁负责数据机密性、完整性和可用性等。

4、管理平面和业务连续性

保护访问云时使用的管理平台和管理结构，包括 Web 控制台 和 API。确保云部署的业务连续性。

5、基础设施安全

核心云基础架构安全性，包括网络、负载安全和混合云安全考虑。该领域还包括私有云的安全基础。

6、虚拟化及容器（Container）技术

虚拟化管理系统、容器和软件定义的网络的安全性。

7、事件响应、通告 和补救

适当的和充分的事件检测、响应、通告和补救。尝试说明为了启动适当的事件处理和取证，在用户和提供商两边都需要满足的一些条目。本域将会帮助您理解云给您现有的事件处理程序带来的复杂性。

8、应用安全

保护在云上运行或在云中开发的应用软件。包括将某个应用迁移到或设计在云中运行是否可行，如果可行，什么类型的云平 台是最合适的（SaaS, PaaS, or IaaS）。

9、数据安全和加密

实施数据的安全和加密控制，并保证可扩展的密钥管理。

10、身份、授权和访问管理

管理身份和利用目录服务来提供访问控制。关注点是组织将身 份管理扩展到云中遇到的问题。本节提供洞察评估一个组织准备就绪进行基于云的身份、授权和访问管理(IdEA)。

11、安全即服务

提供第三方促进安全保障、事件管理、合规认证以及身份和访问监督。

12、相关技术

与云计算有着密切关系的已建立的新兴技术，包括大数据，物联网和移动计算。

什么是云原生？

伴随云计算的滚滚浪潮，云原生(CloudNative)的概念应运而生，云原生很火，火得一塌糊涂，都2022年了，如果你还不懂云原生，那真的out了。

大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；

云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。

何谓云原生？
技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。

可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。

总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

云安全有什么不同？

云安全防护是指保护云计算所涉及的数据、应用和基础架构。云环境（无论是公共、私有还是混合云）需要考虑的安全因素与内部 IT 架构存在诸多共同之处。

主要安全顾虑包括：未经授权的数据披露和泄漏、薄弱的访问控制、易受网络攻击、可用性中断。不管是传统 IT 系统，还是云系统，都会受到这些隐患的影响。和任何计算环境一样，云安全防护也涉及持续提供充分的预防性保护，从而使您能够：

确信数据和系统安全无虞。
能够掌握当前的安全状态。
及时知晓所有异常情况。
能够跟踪意外事件并做出响应。

云安全防护为什么有所不同
虽然很多人都清楚云计算的优点，但却因各种安全威胁而对其望而却步。我们知道对于介于互联网发送的无定形资源与物理服务器之间的事物，您一定很难理解。其实，它是一种不断变化的动态环境。例如，其面临的安全威胁会不断变化。也就是说，在很大程度上，云安全防护就是 IT 安全防护。在理清这两者的具体区别之后，您就不会再觉得“云”这个词没有安全感了。

边界消融

安全与访问权限密切相关。传统环境通常会利用边界安全模型来控制访问权限。云环境具有很高的连通性，这使得流量能够轻松地绕过传统的边界防御措施。不安全的应用编程接口（API）、不严格的身份和凭据管理、帐户劫持以及存在恶意企图的内部人员，都会致使系统和数据面临各种威胁。要防止对云端的未经授权访问，您需要改用以数据为中心的方案。对数据进行加密。改进授权流程。使用高强度密码和双重身份验证。确保每个层级都安全无虞。

如今，一切都处于软件之中

“云”是指通过软件交付给用户的托管资源。云计算基础架构及其处理的所有数据都是动态、可扩展且可移植的。要控制云的安全性，就要对各种环境变量以及与之相关的静态及动态工作负载和数据作出响应，既可以通过工作负载的内在措施（如加密）作出响应，也可以利用云管理系统和 API 作出动态响应。这有助于防止云环境发生系统损坏和数据丢失。

复杂的威胁局势

复杂威胁是指会对现代化计算（当然也包括云计算）造成不利影响的所有威胁。越来越多的复杂恶意软件和其他攻击，比如高级持续性威胁（APT），都会通过利用计算堆栈中的漏洞来绕开各种网络防御措施。数据泄露可能会引发未经授权的信息披露和数据篡改。对于这些威胁，除了及时采取会随着新出现的威胁不断改进的云安全防护实践之外，没有任何明确有效的解决方案。

如下图是菜鸟给某数据中心的私有云安全防护体系架构。

某数据中心私有云架构方案

稻米老人院

2015桃李春风一杯酒，江湖夜雨十年灯。
2016等一场千年兩歇，候一人如约而至。
2017心随万里长相守，雨落千载共白头。
2018雪落长白十三载，故人心归西湖畔。
2019重启征程惊雷响，久伴深村听雨鸣。
2020长白轮转十五秋，湖畔再叙花与酒。
2021两方世界山河共，一纸内外烟雨同。
2022起灵从此年常在，无邪无忧岁平安。

感谢家人们2021年10月-至今的陪伴，感谢陪伴我度过了最艰难的日子。

什么是云计算？

形象点来说说“云计算”：

1、荤段子论：

男人找个女友或老婆是自建私有云，单身约炮或者到娱乐场所消费是公有云服务，按需使用并可弹性扩容，已婚男人找二奶小蜜则属于混合云。

这种解释方式对男人比较适用，通常稍微一解释就心领神会！

2、滴滴出行论：

出行需要用车，云计算或者云服务好比乘坐出租车或专车快车共享单车，随时需要随时用，按用量（路程）付费即可。

自己买车开车是混合云，车是自己的，出去付费停车或加油相当于部分使用公有云，而亚马逊或微软云在国内跟黑车差不多被政策限制。

3、吃货论：

饿了要吃饭，在家里自己做饭属于自建私有云，需要建造厨房购买锅碗瓢盆柴米油盐等，吃完饭还需要自己刷锅洗碗等运维工作，费时费力；外面餐馆提供的就相当于公有云服务，按需胡吃海塞吃完结账抹嘴走人，餐馆后厨如何安排做菜顺序并加快出菜速度就是负载均衡和虚拟化概念；请厨师到家里上门做饭则属于典型的混合云，在资产安全的情况下有限使用公有云。

什么是CI/CD?

概述

CI的英文名称是Continuous Integration，中文翻译为：持续集成。

CD可对应多个英文名称，持续交付Continuous Delivery和持续部署Continuous Deployment。
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：”集成地狱”）。

具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为”CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

CI 持续集成（Continuous Integration）
现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为”合并日”），最终可能造成工作繁琐、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的 IDE 达成一致，那么就会让问题更加雪上加霜。

持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或”主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

CD 持续交付（Continuous Delivery）
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。

CD 持续部署（Continuous Deployment）
对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。

实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。

KVM虚拟化网络的区别

在KVM虚拟化网络中存在

1、Linux Bridge（网桥）

2、vlan

现在的交换机几乎都是支持 VLAN 的。 通常交换机的端口有两种配置模式： Access 和 Trunk。

Access 口
这些端口被打上了 VLAN 的标签，表明该端口属于哪个 VLAN。 不同 VLAN 用 VLAN ID 来区分，VLAN ID 的 范围是 1-4096。 Access 口都是直接与计算机网卡相连的，这样从该网卡出来的数据包流入 Access 口后就被打上了所在 VLAN 的标签。 Access 口只能属于一个 VLAN。

Trunk 口
假设有两个交换机 A 和 B。 A 上有 VLAN1（红）、VLAN2（黄）、VLAN3（蓝）；B 上也有 VLAN1、2、3 那如何让 AB 上相同 VLAN 之间能够通信呢？

办法是将 A 和 B 连起来，而且连接 A 和 B 的端口要允许 VLAN1、2、3 三个 VLAN 的数据都能够通过。
这样的端口就是Trunk口了。 VLAN1、2、3 的数据包在通过 Trunk 口到达对方交换机的过程中始终带着自己的 VLAN 标签。