展开

关键词

流程管理:保障管理效能的推手

随着企业信息化的发展,IT环境日益复杂,对IT管理的要求也就越来越高,那么IT中的管理流程应该如何考虑? IT环境的日益复杂,对IT管理的要求越来越高,无论是对的质量(规范、安全、标准)还是的效率都有更高的要求。 对IT的日益重视,意味着需要有一款专门的流程管理软件对业务的管理工作做支撑。 所以越来越多企业IT部门提出将相关管理流程单独抽离,便于根据的业务特性进行规范化管理,并且实现敏捷的自动化流程。 痛点分析 ? 总结 流程作为IT管理的重要部分,应该在ITOM体系中进行考虑,作为一体化平台的一部分。

2.6K51

浅谈平台的理念【v3.0】

目录 最少要解决如下几个问题 最少要具备如下几个特性 最少要具备如下几项功能 最少要能达成如下几项能力 平台未来的方向和挑战 一句话总结 大家好,我是史丹利「Stanley」,今天来聊聊构建平台的理念 一直在建平台,但确实没有仔细想过这个问题。我对平台有特殊情怀,7年前从腾讯离开开始,就有想法做一套平台,甚至成立工具平台公司。 我认为合格的平台, 最少要解决如下几个问题: 日常繁琐的重复工作 软硬件基础架构资源信息混沌 研职能边界混乱,职责对立,效能低弱 第一要务是解决当下痛点,往往是双手急需释放,刚性需求衍生平台 最少要具备如下几项功能: CMDB 服务树 流程管控 CICD 排班 CMDB,服务树为传统平台必备功能,随着公有云强势下沉,K8S,servermess逐步普及迭代,新型服务治理方式不再需要传统点到点这种中心化的管理功能 流程管控、CICD、排班是传统公司质量管理、SLA达到的重要方式。

22320
  • 广告
    关闭

    【玩转 Cloud Studio】有奖调研征文,千元豪礼等你拿!

    想听听你玩转的独门秘籍,更有机械键盘、鹅厂公仔、CODING 定制公仔等你来拿!

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    管理后台

    开发运管理后台的过程中使用到的东东有:python2.7、django、celery、javascript、jquery等.... 一、登录界面 ? 三、授权申请提交后,管理员后台对收到的任务进行授权处理 ? ? 四、授权处理完成之后,新账号就有了所有页面的访问权限 左侧的新增菜单导航就是管理员授权通过后,新用户才会看到对应的页面 ? 五、管理后台一些功能介绍 1、流程管理,涉及使用者流程的申请,管理员处理流程等功能,需要新增流程的话,直接开发对应的流程任务添加到管理后台中即可。 ? 2、统一账号管理,自己开发的管理模块,没有采用django admin自带的用户管理模块。 ? 4、页面管理,用来动态的添加和删除页面,避免了将页面写死到代码里,后期管理维护不方便。 ? 5、管理平台中具体的子页面功能就不做展示,有感兴趣的可以私信了解。

    83110

    理念篇】的本质---可视化

    于是就开始了的摸索之路,从CMDB、服务台、事件管理、变更管理、可用性管理、容量管理等等逐步去了解,逐步建设自己的系统。 另外从事务或者活动的角度来说,如何对其进行一次或者多次的组合封装,把它们变成一个完整的IT服务,是此时的自动化重点方向。 综上所述,的自动化最终要实现可视化,IAAS和PAAS是可视化的一个高度体现。可视化是自动化的更高阶表现! 第二部分,可视化服务度量 在我的理念中,一直倡导数据驱动的数据化能力非常重要,一方面也体现出你对的理解是什么样的,从数据上可以看到你很多运经验的提炼;其次利用数据可以发挥的驱动能力,从某种意义上来说,数据不会说谎。 因此我说可视化的能力代表了的能力,可视化的程度越高,的能力越高。那么你现在到底可视化了哪些服务,并能进行度量?

    54120

    理念篇】应用三部曲

    接触过一个项目组,研发按照自己的喜好,选择了cassandra、mongodb、mysql、redis四种存储,所有的好与不好,都是从自己的角度描述(忌讳啊),最后这个产品的结果是质量问题频出、无法快速迭代、还无法管理 基于统一的协议,后续的测试框架都很好实现;基于统一的协议,后续的管理、监控也很容易实现。 第二步:服务化 这一部分是对上面的组件化服务进一步升华,也可以把他理解成“架构及服务”。 此时运该驱动让这类组件管理公共化,走向集中式,统一实现以上所提到的业务需求。再往前一步,做可视化管理,避免在操作系统中进行命令式管理,从而提高维护的效率和质量。 最近我们也在某个核心业务上,维和研发、测试、项目管理组一起启动了个双中心的服务质量优化专项。 最后感谢下,在UC遇到了很多不错的研发、测试、产品、项目管理的同事,他们给予维和我个人的合作和支持,让我一年多有机会实践了很多运的想法,谢谢你们!

    42010

    管理小知识

    把CentOS启动进度条替换为详细信息 : CentOS 6 启动的时候,是一个进度条,并不像以前CentOS5启动的时候显示启动的信息,这是因为有一个参数所控...

    31540

    日常管理(三)

    #ifup ens33 :打开ens33这个网卡 有时候我们通过远程连接工具连接服务器,如果必须重启某个特定的网卡我们需要这样操作: #ifdown ens33 && ifup ens33 在日常的当中

    70650

    日常管理(二)

    an 查看系统的网络连接状况 ESTABLISHED:客户端与服务端已经建立数据连接(并发连接数) TIME_WAIT:客户端与服务端连接还没有断开,处于等待的一个状态 LISTEN: 侦听状态 实用管理命令 指定保存位置(但是我们保存的1.cap是不可以直接cat查看的) 如果不晓得一个文件是什么类型的文件可以使用 file /tmp/1.cap #tcpdump -r /tmp/1.cap -r: 读取 实用管理命令

    69960

    【HDFS】管理

    管理 可视化界面 通过50070端口,可以访问HDFS Web UI:http://activeNameNodeHost:50070,需将activeNameNodeHost自行替换为主节点IP,

    12720

    日常管理(一)

    监控系统状态 w: # w/uptime:查看系统负载 16:08:52 up 2 days, 21:49, 1 user, load average: 0....

    61140

    Hudi的管理

    管理员/人员可以通过以下方式了解Hudi数据集/管道 通过Admin CLI进行管理 Graphite指标 Hudi应用程序的Spark UI 本节简要介绍了每一种方法,并提供了有关故障排除的一些常规指南 Hudi库使用.hoodie子文件夹跟踪所有元数据,从而有效地在内部管理该数据集。 初始化hudi表,可使用如下命令。 .111415c3-f26d-4639-86c8-f9956f245ac3_20181002180759.log.1}]| [] | hoodie:stock_ticks_mor-> 统计信息 由于Hudi直接管理 将来,将在项目中添加更复杂的调试/管理UI,以帮助自动进行某些调试。

    67320

    快速学习-RocketMQ管理

    管理1 集群搭建1.1 单Master模式这种方式风险较大,一旦Broker重启或者宕机时,会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。 2 mqadmin管理工具注意:1. 执行命令方法:.mqadmin {command} {args}2. 几乎所有命令都需要配置-n表示NameServer地址,格式为ip:port3. 值-ttopic 名称-h打印帮助-nNameServer 服务地址,格式 ip:portqueryMsgByUniqueKey根据msgId查询,msgId不同于offsetMsgId,区别详见常见问题 kkey-vvalue2.8 其他名称含义命令选项说明startMonitoring开启监控进程,监控消息误删、重试队列消息数等-nNameServer 服务地址,格式 ip:port-h打印帮助3 常见问题 3.1 RocketMQ的mqadmin命令报错问题 问题描述:有时候在部署完RocketMQ集群后,尝试执行“mqadmin”一些命令,会出现下面的异常信息: org.apache.rocketmq.remoting.exception.RemotingConnectException

    54210

    从ITOM到AIOps:IT管理向智能的进化

    面对这些新形势下的挑战,IT 管理(ITOM)需要从原有的人工加被动响应,转变为更高效、更智能化的体系,为新形势下的IT系统保驾护航。 AIOps重新定义了IT管理方式,为IT团队适时提供适当信息,以便实现以下几点。 通过采集当前环境中的数据,集成现有IT管理工具,利用聚合数据分析的技术,对IT系统中各个环节的问题进行快速定位、故障排除和预测。 全局日志检索 以一个典型金融行业为例,他们有上百个业务系统,面对每天产生的大量日志数据(几TB),日常过程中,当人员需要排错或日志巡检时,需要逐台登录服务器, 无法集中查看和管理日志数据;另外, 传统IT管理平台,即 ITOM 平台,往往是为完成单一管理任务而设计的,更偏向于管理某一细分专业领域。

    2.2K50

    VMware云管平台管理

    摘要 跨 SDDC 和多云环境从应用到基础架构的智能 IT 管理。 其中有三大块内容,一个是自动化部署的vRA,一个是做智能的vR Ops,以及做成本分析的vRB,这三块共同支撑起了云管平台。 这期我们重点来介绍vR Ops。 vRealize Operations——云智能化 在整个平台中,vRealize Operations实现了性能的管理、容量管理、成本管理、配置管理以及合规性管理。 通过性能和容量监控vSAN环境。 SDDC健康概览仪表盘 单一控制台监控整个SDDC的状态。 扩展支持。 VMware对vSphere和云计算环境的深入理解,提供了智能的容量分析和规划能力,包括对vSphere虚拟化环境的CPU, 内存, 存储以及网络等资源的现有容量使用情况统计, 容量使用趋势, 进而帮助管理人员合理规划虚拟化环境的资源

    2.8K50

    平台-TcaplusDB事务管理

    [TcaplusDB知识库]平台-TcaplusDB事务管理 事务管理基本贯穿整个操作的始终,从机器上架,初始化,安装,升级到下线,从业务的创建和删除,分区的创建和删除,表的建立和删除,以及备份 ,重建,回档等,都是通过事务管理模块来实施的,事务管理的核心在于tcapcenter模块。 在如上所说的各个操作中,在其他章节已经介绍了如何操作,这里不再赘述,只介绍事务处理的页面,如何查看事务的执行状况,以及怎么解读异常信息并操作等; 点击“平台”->“事务处理”进入事务处理页面 点击 “平台”,会默认选择展示一个集群下面的全部事务,如果查询的事务不在这个集群,则需要在如下红色框住的“集群”位置,选择需要查看的集群,点击“查询”按钮,则会刷新事务页面,得到最新的事务列表 筛选需要查看的事务 同时具备丰富的生态、便捷的迁移、极低的成本和五个九高可用等特点。客户覆盖游戏、互联网、政务、金融、制造和物联网等领域。

    17450

    046.集群管理-日常

    一 Node管理 1.1 Node隔离——方式一 在硬件升级、硬件维护等情况下,我们需要将某些Node隔离,使其脱离Kubernetes集群的调度范围。 kubectl patch node k8s-node1 -p '{"spec":"{"unschedulable":"true"}"}' 注意:将某个Node脱离调度范围时,在其上运行的Pod并不会自动停止,管理员需要手动停止在该 二 更新Label 2.1 资源标签管理 [root@k8smaster01 study]# kubectl label pod kubernetes-dashboard-66cb8889-6ssqh kube-system #删除label [root@k8smaster01 study]# kubectl get pods -L role -n kube-system #查看label 三 Namespace管理 [root@k8smaster01 ~]# kubectl config use-context ctx-dev #将当前运行环境设置为ctx-dev 注意:如上设置,当前的运行环境被设置为开发组所需的环境

    44010

    中的接入管理梳理

    关于接入管理,之前是想做成接口型,通过配置组合起来,实现灵活的调用方案。 当时画了一个概要的图。 ? 如果把上面的路径和技术序列联系起来,就可能是下面的一些解决方案。 数据库层的接入可以提炼出DAO层,通过工厂模式来提供灵活的配置接入,这会是一个通用的接口,同时其他数据库的接入也可以通过这种方式带来接入,提炼的结果就是对于数据库类型和接入方式,即可完成数据库的接入管理 这些其实就跟管理层的工作类似,需要根据实际的情况和配置来得到一个最优路径,然后由具体的任务层来负责执行。 所以上面的思路抽象之后,就是得到接入路径,然后执行接入任务。 第三种,需要ops端具有直连的权限,能够直接访问数据库,则ops端需要配备完善的接入管理。这个不能说不合理,只是对于ops来说会相对重一些。 所以对于这个基本的接入管理需求,会分为:系统接入管理和数据库接入管理,映射到这个场景中,就是如下的一个初步选择 2)ops_to_cm,cm_to_db

    22520

    【DevOps】构建面向应用的管理新思维

    为什么线上问题永远是人的黑锅?带着这些问题我们来一探究竟。 今天要和大家阐述一个新的思路——建立面向应用的管理新思维,带着这个思路去寻找维新的解决方案,因此把面向应用管理抽象总结如下: ? 把的能力建立在面向应用的维度上,把面向应用的IT能力分成三部分: CMDB即IT资源管理系统 支撑一个应用运行到底占用了哪些资源? 通常分成开发、测试和角色,但真正到企业内,角色的划分会细致的多;其次这个角色也是随着管理模式变化而变化的,测试人员可能来做生产环境的部署。 这个自动化能力就不是自动化,而是IT自动化。 再回到自动化,在面向应用的自动化场景上,依然可以通过服务编排的模式来实现。但是回到其他资源上,就逐渐失去和应用的关联,从管理方便性的角度来说,更是如此了。 面向应用的管理新思维,是切实有效的,给过去的很多未解问题提供了解决方案,这也是我过去不断强调要“建立以应用+研发为核心的组织体系”的原因。应用的是贴近业务的,因此应用是驱动力最强的。

    78411

    平台中的脚本管理

    脚本管理的内容之前写过两篇,供参考。 平台设计中的脚本管理 web脚本编辑器ACE Editor 在这个阶段,也收获了一些经验,所以准备把这部分的内容做扎实一些,同时有些内容会延伸一下。 我会从脚本管理和工具管理两个大的维度来说。 脚本管理是基础功能,需要实现的功能就如同任务调度一样,是一个通用的入口 先说一些边界,脚本管理中的脚本是不能直接执行的,所有的任务都是不支持命令,最细粒度就是脚本。 从功能划分上,大体有下面的几个方面:   1)脚本内容管理:Python,shell,Java,SQL等   2)执行方式:本地和远程(服务器端执行脚本,客户端,中控端)   3)参数管理:脚本配置支持多个参数 工具管理是在脚本管理的基础上的扩展,脚本管理其实就类似于积木的转配和组合,更希望是做成一个工具箱的方式。可以做各种接入和适配,然后根据我们的需求在指定的场景中完成指定的任务。

    1.6K50

    管理之线上故障处理原则

    改进措施 根据回顾问题提出的改进措施,以正式的项目管理方式进行统一管理,采用 SMART 原则来跟进 参考 分布式服务架构原理、设计与实战

    1.4K30

    扫码关注腾讯云开发者

    领取腾讯云代金券