首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

=平台+数据

会比开发更加重要 的发展日新月异,曾几何时,仅仅是被认知为跑机房,装系统,设计网络,给开发擦屁股。...但是现在运变得极度重要,职责也更加细化,譬如稍大点的公司就将划分为基础,网络,DBA, 应用,架构师。...其实我个人认为系统架构师应该都安排在运里,开发团队应该率属于团队才好。 进入云时代后,中等层次的慢慢会被淘汰,底层次的会越来越少,高水平的需求量则日益增长。为什么这么说呢?...这其实是反应对的要求会越来越高,不但要掌控产品的稳定性,做好服务保障的最后一公里,还要具有系统设计的能力。 现有发展方向的问题 也越来越朝着平台化,自动化,自助化方向发展。...前面讲的是基础平台层面的,我们其实更多的是要对应用进行更细致的观察。在Borg之上的应用可以是非常复杂的,应用的关联也是非常复杂的,微服务的兴起导致链路非常长,所以我们有了全链路追踪的需求。

3.4K50

linux

Linux服务器被黑遭敲诈,如何在3小时内紧急逆袭 作者介绍:陈浩,北信源研发工程师,五年Linux工作经验,热衷技术研究、实践和团队分享。...看完就会用的 GIT 操作图解分析 无论你是前端还是后台,无论是还是移动端研发,GIT 是逃避不了的东西,当然你说你要用 SVN,那不在这次的讨论范围之内。...本文主要讲述如何在 Linux 下连接 V** 服务。....… 10 个非常有趣的 Linux 命令 Linux 当中有很多比较有趣的命令,可以动手看看,很简单的。...HTTP原理和SSL原理 HTTP协议相关知识也属于前端必备基础知识,是很多公司面试时必问的知识点 一步一步打造 MySQL 高可用平台 作者一步一步打造 MySQL 高可用平台的经验分享

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

管理之线上故障处理原则

应急目标 在生成环境发生故障时快速恢复服务,避免或减少故障带来的损失,避免或减少故障对客户的影响 应急原则 应第一时间恢复系统,而不是彻底解决呢问题,快速止损 明显资金损失时,要第时间升级,快速止损 指标要围绕目标...对数据库的负载、慢查询、连接数等监控 对缓存的连接数、占用内存、吞吐量、响应时间等监控 消息队列的响应时间、吞吐量、负载、堆积情况等监控 定位问题 分析定位过程中先考虑系统最近发生的变化,需要考虑如下几方面 故障系统最近是否上过线...依赖的基础平台与资源是否升级过? 依赖的系统是否上过线? 运营是否在系统内做过运营变更? 网络是否有波动? 最近的业务量是否涨了? 运营方是否有促销活动?...做了哪些事情,及时发生故障,也不会产生影响? 改进措施 根据回顾问题提出的改进措施,以正式的项目管理方式进行统一管理,采用 SMART 原则来跟进 参考 分布式服务架构原理、设计与实战

2K30

【扯淡篇】故障的觉醒力?

,我们是认真的,故障,我们更是认真的。故障,真的是最好的老师,因此我才想写这篇文章! 最近互联网也是非常有意思,接二连三的发生故障,让我们一起先回顾一下。...如果广义的去看这个,我还会把它归结成问题。不过对于以上的故障,从的角度来说,我依然会说官方结论不够专业,希望内部不是这样的哈。...不断的审视我们的能力和IT的能力,说“故障最好的老师”的原因也在于此,它能够不断驱使我们走向更高的成熟度。...是复盘的首要负责人,复盘是为了找到根因(Root Cause),根因和故障现象不同,举个例子,故障现象是交换机故障,根因是因为技术架构没有对交换机故障做到容错,根因是对这种故障缺乏有效的临时应对机制...你们真的重视故障了么?你们真的重视了么?故障不能带来人的春天,从根本上去意识到的重要性,那才是人真正的春天。

63210

掌握必备技能--问题故障定位

同样对于内存有些概念需要清楚: 主存 虚拟内存 常驻内存 地址空间 OOM 页缓存 缺页 换页 交换空间 交换 用户分配器libc、glibc、libmalloc和mtmalloc LINUX内核级SLUB...要监测 IO 性能,有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。...网络 7.1 说明 网络的监测是所有 Linux 子系统里面最复杂的,有太多的因素在里面,比如:延迟、阻塞、冲突、丢包等,更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为...Linux 网络子系统的问题还是别的设备的问题,增加了监测和判断的复杂度。...目前供职于滴滴基础平台部-技术专家岗位,主要负责分布式Ceph系统。个人主要关注的技术领域:高性能Nginx开发、分布式缓存、分布式存储。 来源:简书,转载请联系作者获得授权

1.1K20

故障自愈——游戏的终极福音

报名请点击【阅读原文】 Chapter 1 【故障自愈的思路及解决方案】 故障自愈对意味着什么 在游戏领域,各种专业化解决方案越来越成熟和丰富,各类自动化工具不断涌现,包含发布变更、容量伸缩等多种场景的游戏云服务也在逐步优化和推广中...从团队核心价值来看,个人认为,相比起对各种操作的需求,业务侧更需要提供的是全面而高水平的业务质量保障服务,包括对业务架构及部署的优化服务,包括专业而精细化的游戏健康度管理,以及快速的故障处理服务等...4) 方案涉及的所有环节都需要业务自己实现,没有平台团队帮助实现公共的、基础的功能和服务。当涉及的业务很多、异常场景很多的时候,投入成本极高,而收效却往往不明显,性价比很低。...可以很轻松的接入到自愈中。 故障自愈能够帮助业务第一时间查明问题原因、并马上恢复故障,后续还能帮助输出阶段性待优化问题形成闭环管理。...故障自愈总体实现方案 故障自愈是一整套严谨的故障自动化处理服务,通过和网平、作业调度平台、配置管理中心、告警单据系统等诸多周边系统自顶至下的全流程打通,轻松的实现了发现告警、关联配置信息、智能告警收敛分析

2.3K80

DevOps之平台构建

写在前面的话 如今很多人认为devops将彻底取代传统,我不这么认为,在我看来devops只是很大程度上的代替了传统的手工操作,人员只需写好自动化脚本,利用自动化工具(zabbix,elk...因此Devops能否顺利落地,平台的建设将会很重要。本文主要简单介绍下我司的三大平台职责 ? ?...平台 当前我司平台主要有3个: 持续集成和交付 ①基于Jenkins持续构建 ②支持容器化打包和部署 ③发布平台,支持灰度发布,异常快速回滚 监控告警平台 ①完善的监控体系:覆盖机器、网络、服务和客户设备维度...平台演示 ?...后记 这三大平台用的都是开源系统,总共有12个系统,Sonar、Jenkins、Ranche、Consul、ELK、Admin-Service、Zabbix、Prometheus、Smokeping

4.3K20

他山之石——平台哪家强?

当云平台出现网络故障、系统故障等问题,这对云租户/用户有时甚至是致命的,所以不少 SRE 是由高级别开发人员转型而来。...当出现用户请求调用失败或者出错时,平台支持整个调用链路的分析与故障环节定位。 日志数据采集与分析:日志的采集主要是为了辅助应用调用链路分析以及性能监控,人员无需进入后台去大量翻找日志。...目前国内各大云厂商也基本都提供了应用平台,包括腾讯蓝鲸、阿里 ARMS、华为 APM 等。以下是这几个平台能力的简要对比: ?...除上述的工具和平台之外,AIOps 也逐渐成为未来的一个趋势,AIOps 通过 AI 技术的运用来进行智能业务故障诊断,同时自动恢复应用故障,企图让研发组织彻底告别人肉时代,笔者也万分期待这天的到来...人员不用担心因 AIOps 失业,工具和平台只是提升效率,不会取代

2.1K50

蓝鲸 腾讯游戏平台

游戏的两极化(高星级/长尾级)、差异化、数量多、变化快等特点决定了任何一、两个平台都不可能承担起所有的工作。目前同学已经通过iJobs实现了所有操作的作业一键化,但这还远远不够。...这类复杂场景占用时间是很夸张的,一次开区或一次搬迁前前后后需要数日甚至数周、人员实际消耗精力的时间也有7、8个小时甚至彻夜standby不能休息,往往在执行之外,各种沟通询问和等待时间的占比非常大...【对蓝鲸App开发者而言】 蓝鲸提供了开放的开发平台,它允许业务人员设计自己或客户最需要的app,并借助蓝鲸为app开发者提供的一系列配套设施,多快好省的产出app服务。...• ->规划。 3. 提高团队整体价值。 • 大大提升自动化程度,提升支撑效率。 • 通过尽可能的操作简化和自动化尽可能消灭人为失误给业务带来的损失。...二、【数据类App】 数据查询、修改类的app相比专业的数据类平台,具备速度更快、使用更简单、体验更好的优点,特别适合于对特定信息的、非常频繁获取和变更的场景,甚至可以是不需要任何查询条件的、进入即所得的体验

8.6K90

Linux常见故障排查和处理的33个技巧汇总

作为linux,多多少少会碰见这样那样的问题或故障,从中总结经验,查找问题,汇总并分析故障的原因,这是一个Linux工程师良好的习惯。...下面汇总了我做项目过程可能出现的故障及解决方法,看看是否与你有共鸣,并对你有帮助?...看这错,我就问他是不是在windows下编写的脚本,然后在上传到linux服务器的……果然。...序号 故障点 分析与解决 1 Linux系统安装初始状态时,找不到硬盘,并无法进入下一步安装 进入COMS设置,找到硬盘设置的相关选项,并设置为兼容模式 2 Linux系统安装时,在硬盘分区完成后,无法继续安装...云计算及高薪实战班》2018年03月26日即将开课中,120天冲击Linux年薪30万,改变速约~~~~ *声明:推送内容与图片均来源于网络,部分内容会有所改动,版权归原作者所有,如来源信息有误或侵犯权益

3.3K60

远离故障的十条原则

线上更新要有回滚,在同样的环境测试过再上线 是一门经验的学科,是一门试错的学科。永远要做最坏的打算。不要寄希望于每次都有逆天的好运气。...设备故障本来就是小概率事件。故障后,备份在失效。可以收拾东西,准备找下家了。 在说一次,不要寄希望于可有可无的运气。重要的事情说三遍。...这些帐户包括linux用户还包括数据库帐户 你的sudo权限是否开放给了某些用户,这些用户是否安全 用户密码是否经常修改,是否加密不让具体人员直接看到,密码强度是否足够,密码重试次数达到一定次数是否黑名单...你的生产环境和线下环境是否隔离,数据库是否和外网隔离 是否一些工作明明可在开发库和测试库做,却被放到生产环境上去了 是否有专门人员负责线上应用发布,从而避免开发人员接触生产环境 交接和休假最容易出故障...搭建好报警平台,及时获得出错信息;搭建性能监控平台,了解历史,获得趋势,预测未来。 自动切换需谨慎使用 仔细一点,偏执一点,检查,检查,再检查。重要的事情在说三遍。 简单即是美,越是简单,越是健壮

44520

规范:线上故障处理的流程模板

流程机制故障发现后,On-Call 的 SRE 或 故障指挥官 有权召集相应的业务开发或其它必要资源,快速组织 事故处理小组。...如果问题和恢复过程非常明确,故障指挥官 仍然是 SRE 或 ,就不做转移,由他来指挥每个人要做的具体事情,以优先恢复业务优先。...详细流程图```sequenceOnCall->故障:发现故障OnCall->OnCall: 初步分析故障原因OnCall->事故处理小组: 召集业务开发或其它必要资源事故处理小组->事故处理小组...: 事故反馈(10-15分钟一次)事故处理小组->事故处理: 事故排查OnCall-->高管: 问题疑难,影响范围很大,事故升级高管-->事故处理小组: 全权管理,进行下一步协商处理事故处理->事故处理...->事后总结: 组织故障复盘会议Note right of 事后总结: 总结原因,解决问题事后总结->事故处理小组: 输出会议总结,故障报告```COPY事故业务现象由谁在什么时间点报什么问题,尽量详细

2.3K20
领券