运维知识内容
运维知识 序列运维架构层级内容描述监控安全备份自动化自动化/DevOps云计算详细内容1客户端层DNS浏览器缓存->本地hosts->本地缓存->DNS服务器(本地缓存、迭代)->根->公网IP地址、HTTP-DNS、机房内部智能DNS监控宝、基调、加速乐、牛盾、安全宝、阿里云盾云存储API阿里云-C
·
运维知识 | |||||||||||
序列 | 运维架构层级 | 内容描述 | 监控 | 安全 | 备份 | 自动化 | 自动化/DevOps | 云计算 | 详细内容 | ||
1 | 客户端层 | DNS | 浏览器缓存->本地hosts->本地缓存->DNS服务器(本地缓存、迭代)->根->公网IP地址、HTTP-DNS、机房内部智能DNS | 监控宝、基调、 | 加速乐、牛盾、安全宝、阿里云盾 | 云存储 | API | 阿里云-CDN | 1、工作流引擎、权限管理。这两者都是基本的功能,因为其中会涉及流程,所以需要统一的流程引擎平台。另外需要部门、角色、用户的权限管理统一管理,不同业务配置不同系统的使用策略即可,这一块可以统一实现在单点登陆系统中。 2、基础设施物理层。这个视角和传统模式有些不同,主要是公有云的存在。因此在基础设施物理层这块,已经把云端资源当作一个底层基础设施来看待,后续的资源获取完全不同,其他的资源对象依然没有变化,依然是机房、机柜、网络、服务器,等等。 3、配置及服务,把配置当作服务来看待。比如说机房信息、服务器信息、人员信息、服务信息、业务信息以及他们之间的物理和业务拓扑关系等,上层的所有系统都应该关联到CMDB,变更后的信息必须实时反馈到CMDB中,确保其他系统能同步这份变化。因此大家都把CMDB系统当作运维的核心系统来对待,便于后续各个系统之间的互通。 4、服务——基础、ITIL服务和DevOps——高级。ITIL是面向流程的(运维平台建设中不做重点,不要主动去构建流程,会影响运维的敏捷性)。 基础部分实现一个事件和HelpDesk即可,事件管理在告警转换成事件之后,可以完整地记录,便于我们事后的原因分析,能挖掘一些问题,比如说是否某个业务、某个人、某类机器经常性故障,那就需要重点关注下。 高级服务的部分带来价值的,比如说可用性管理、能力管理和连续性管理。可用性直接的导向就是业务的质量;能力管理直接的导向就是成本管理;连续性管理也是和质量戚戚相关,如业务的容灾、备份管理等。但这些管理都不要在流程层面上去看,需要在一个平台中进行全面的可视化管理。 5、基础设施及服务。把底层运维资源的管理封装成一个一个的服务,供业务自动化平台使用。我把DNS、LVS(或者F5)甚至OS上的配置管理都看着基础设施部分,适当地向上延伸了一下。简单的划分原则是,在业务架构之外的,都可当着基础架构部分了。很多运维团队的建设重点都在这块。 6、架构及服务。把业务架构中的共性需求都剥离出来,抽象成一个一个的服务,最终让研发只需要关注自己的业务代码即可,比如说统一文件存储、统一Nosql存储、统一RDS存储、统一队列等。这块对运维的质量、效率、能力等影响最大。 “如何化解研发和产品之间的矛盾”中重点阐述过服务公共化是唯一的解决之道。现实中如果有研发开发了一个公共组件交给运维,而不提供完整的Webadmin或者API的话,你也就可以认为他是在耍流氓,运维必须有严格的完整性交付要求。 7、数据及服务。只要有线上服务在运行,服务数据流经过的一切节点产生的数据,采集、存储和分析起来,供不同的运维场景使用。比如说自动化调度,可以根据业务涉及的基础节点资源使用情况,制定对应的自动化调度策略;可以在数据中直接进行故障定位;可以在数据中做安全分析。之前的文章“数据驱动运维”中介绍过我做的一个数据分层体系。 8、监控及服务,有数据的地方才有监控。脱离这个原则,你做的都是告警,并且告警的成本会越来越大,不成体系。 9、持续集成。这条线是把一个个的程序包交付到各个环境, 一个程序部署到生产环境之后,需要实时的运行报告反馈回来,确认变更的效果。如果持续部署平台化之后,真正的执行部署工作会不断前移,甚至可能直接交付给研发。此时的状态报告,更是有必要,不需要人去登录主机tail日志看是否正常。这个地方和“数据及服务”的能力关联很大,没有前面强大的数据服务能力。 10、面向业务的运维平台。不同的业务会有不同的调度策略和服务使用策略,需要在更上层完成面向业务的统一调度,这个是全应用的视角,和持续集成是有一些区别的。在没有这个平台之前,一个完整的业务上线,需要做很多操作,比如说DNS变更、LVS变更、OS初始化、自动化测试、持续部署、持续反馈、监控、业务调用关系配置,等等。面向业务的调度平台,就需要有一种调度能力,指挥底层各个平台为它服务,它本身不实现任何服务接口,是一个服务的集成者。 11、运维统一门户。每个运维系统都有任务或者信息与自己相关,如果运维人员每天要去面对那么多的运维系统,会非常痛苦。在统一门户里面分成两个部分,一部分是任务中心,把底层所有的事务状态都同步到任务中心中,表示我要做什么;信息中心,就是让运维人平时关注的业务状态Dashboard直接推送到信息中心中,表示我要关注什么。 12、平台的目标就是自动化和数据化一切,并且最终可视化,从而确保质量、效率和成本几者之间的平衡。 | ||
浏览器 | 缓存协商(Last-Modified、Expires、Etag)、组件分离、提高浏览器并发数、避免静态资源Cookie上传 | ||||||||||
2 | 外部层 | 第三方CDN | 智能DNS/GSLB->反向代理缓存->源站 (各类API如:带宽、预缓存、缓存刷新) | ||||||||
云计算、外包 | 公有云、混合云、运维外包服务、APM(应用性能管理) | ||||||||||
3 | 网络层 | 核心层 | 网关设备(outside、inside)防火墙、路由器、Ipsec VPN | 同上、网络监控 (Smokeping) | 防火墙 | HSRP、VRRP | SDN | 阿里云-VPC | |||
汇聚层 | 三层交换 动态路由(OSPF)、静态路由、EC(端口汇聚)、MSTP+VRRP | ||||||||||
接入层 | 二层交换 (VTP、SPF、Trunk、端口安全)CCNA级别 | ||||||||||
4 | 集群层 | 负载均衡+高可用 | 四层负载均衡 | 开源:LVS(IP负载均衡)+Keepalived 商业:F5、Netscaler | 舆论监控(第三方) | WAF(Nginx+Lua) | VRRP | 平台开发 | 阿里云-SLB | ||
七层负载均衡 | Haproxy、Nginx、Apache(根据User-Agent、URL等进行负载分发) | (IAAS) | |||||||||
5 | 应用服务层 | 反向代理缓存 | ATS、Squid、Varnish(预缓存、缓存刷新) | 业务监控(监控接口) | 代码安全 | 集群 | 平台开发 | ||||
(第三方) | |||||||||||
Web层 | Apache、Nginx、Tomcat、Jboss(GZIP、Web服务器缓存、epoll、sendfile、CPU绑定、自身性能优化) | 流量分析(Piwik) | GitHub扫描 | 自定义开发 | |||||||
应用层 | PHP Python Java C C++ 模块理解、代码部署、(OPCache、LocalCache) | 远程执行+配置管理+云管理:SaltStack | 各种SAAS服务 | ||||||||
SOA层 | SOA框架(dubbo、resteasy)、业务模块、协议(RPC、restful)、ESB、服务注册与发现(Etcd、Zookeeper) | 服务监控(提供API) | 框架安全 | ||||||||
分布式层 | 消息队列 | ActiveMQ(成熟)、RabbitMQ(成熟、案例多)、ZeroMQ(中)、RocketMQ(中) | 防火墙、权限控制 | 集群 | 基于SaltStack+etcd+OpenStack/Docker的自动化扩容 | 阿里云-消息队列 | |||||
文件存储 | 单机存储 | 机械硬盘、SSD、文件系统(ext4、xfs)、LVM | 安全监控(WAF) | 软件自身访问控制 | Raid | 阿里云-块存储 | |||||
单机存储扩展 | 文件分发(多级分发)、文件同步(rsync、HASH Tree、inotify)、DRBD、DAS | 无 | 过载保护 | OSS | |||||||
共享存储 | NAS[NFS(Unix/Linux)]、SAN、iSCSI | rsync | |||||||||
分布式存储 | GlusterFS、MooseFS、FastDFS、Ceph | 分布式 | |||||||||
DAL | 数据访问层 | 未开源:淘宝的TDDL、开源:360(Atlas)、阿里(Cobar)、MyCat、MySQL-Proxy、根据业务定制开发 | 自带 | DAL | |||||||
数据层 | 分布式缓存 | Memcached、Redis(客户端分片、Redis Cluster、Twemproxy、Codis) | 数据库监控 | 权限控制 | 集群 | 数据库运维平台 | 云数据库-RDS、 | ||||
Mongodb、Redis、 | |||||||||||
NoSQL | Redis、LevelDB(SSDB)、CouchDB、Mongodb、Couchbase 、Cassandra | 集群 | Memcached、 | ||||||||
DB | MySQL(Drizzle、MariaDB、Percona Server、Percona Xtradb Cluster、MHA)Oracle(DG、GG、GC)、PostgreSQL、SqlServer | 数据库备份 | OceanBase | ||||||||
大数据 | Hadoop生态圈(HDFS、Hive、Hbase、Zookeeper、Pig、Spark)、Hadoop+Mahout智能推荐、kafka和Storm实时分析 | Zabbix监控平台 | kerberos、继承其它系统 | 自定义 | Ambari、Cloudera Manager | E-MapReduce | |||||
6 | 基础服务层 | 运维相关 | ownCloud、项目管理(Jira、WIKI、Redmine、Bugzilla、Sonar、CodeReview) | Puppet、Chef、SaltStack、Ansible | 日志服务 | ||||||
应用相关 | 日志收集平台(ELKStack)、自动化部署平台、Job管理平台 | 操作审计 | |||||||||
系统相关 | LDAP、DNS、DHCP、Mail、SMS、Git(Github、Gitlab)、Yum仓库、操作审计(xenapp) | 资源编排 | |||||||||
7 | 操作系统层 | 环境初始化 | 基础性能优化、监控Agent、SaltStack Minion、DNS、rsyslog、logstash、安全审计 | 系统监控 | 防火墙、权限控制 | 集群、热迁移 | |||||
8 | 基础设施层 | 设备上下架 | 网络配置、标签化、配置检查、Raid构建、iDrac\ILO\IMM、操作系统安装(Cobbler)、资产录入(CMDB) | 机房巡检、物理监控 Zabbix IPMI | 物理安全、灾备 | bonding、灾备 | 公有云(AWS、青云、阿里云) | 阿里云-ECS | |||
IDC托管 | 需求分析、IDC选型、网络测试、谈价格、签合同、设备采购(原厂vs渠道) | 第三方评估网络性能 | 防忽悠,尽量按月付费 | 多家IDC对比 | 私有云(OpenStack、Cloudstack) | ||||||
9 | 测试和开发相关 | 运维协助:性能测试(TCPCopy)、单机监控(nmon)、环境规划(开发、测试、预生产、生产)、CI(持续集成)、自动化部署、Job管理平台 |
更多推荐
已为社区贡献11条内容
所有评论(0)