项目管理多重要,看完本文就知道(程序员,项目经理必看)

杨y 发表了文章 • 0 个评论 • 114 次浏览 • 2017-11-29 14:41 • 来自相关话题

项目管理一直都是项目经理所需要掌握的必备技能,它可以有效的进行整合,以达到高效、高质、低成本的完成企业内部各项工作或项目的目的。近来让项目管理可视化是大家一致在探讨的问题,数人云今天给大家带来的文章将阐述为什么项目管理可视化的重要性,同时开发人员熟练使用项目管理工具可以让其在整个开发生命周期中更好地掌握项目进度。

项目经理与项目管理

可视化项目管理是使用图形、图片、以及图片来显示项目信息。对于那些偏爱于从视觉上获取信息的人,通常会对他们的任务列表进行涂鸦或将其绘制成列表,而那些喜欢创建列表的人则会选择一个有序的任务列表,现在可以看到的是,项目管理工具在满足这两种偏好方面越来越好,并且使得与需要它的人直观地分享信息变得更加容易,如此同时,通过简单的图形可以让其他人更容易掌握自己复杂的想法。

可视化的重要性是什么?

与文字段落相比,在图表上交流复杂的结构或共享数据点要容易很多,从古至今一直如此,今天,技术可以让我们更容易提取所需的数据并且以一种简单易懂的方式呈现出来,方便大家查阅以及阐述想法。








Buzzsumo报道称,视频内容的平均股价上涨了近一倍,而早在2010年,《福布斯》就报道称,视频是高管们的关键信息来源,凸显了以在线视频格式观看业务内容的上升趋势。

基本上,网络正从一个基于文本的环境转变为更多的视觉、图形和视频的环境,这也影响了工作场所的交流。

这对项目经理意味着什么?

与项目经理一起工作的团队成员在其他地方看到不同格式的信息,例如,视频在Facebook上的兴起意味着现在比以前更多的人在消费视频内容,更习惯看到它并搜索它,人们把他们的沟通喜好带到了工作场所。

如果项目的赞助者可以下载一段三分钟关于经济状况的视频,或者是一项复杂的健康研究,他们就会期待同样的信息——提炼成容易消费的数据块——用于他们的项目。

如何在项目中加入视觉传达?

无论是将困难的过程分解成易于遵循的过程图,还是在可视化计划中显示项目进展,都可以通过一些方法共享项目性能数据,从而使您的射中更容易理解消息。

以下是5种“做”视觉项目管理沟通的方法:

1、工作视觉规划工具

无论团队使用的是敏捷方法还是基于瀑布式的方法(或两者混合),都可以考虑您可以与团队成员共享项目进度的方法。

许多项目经理从Gantt图中进行复制和粘贴,并将它们列在项目报告当中,又或许是在一个有日期的表中,考虑一下显示Gantt的卷图版本,或者创建一个具有里程碑跟踪的可视化计划,它只显示关键的里程碑,这是一种比日期列表更有效的共享项目进展的方式。 可以对看板做同样的事情:创建一个显示主要项目步骤和进度的高级版,并在进度报告中包含一个快照。

2、Mindmaps

Mindmapping软件的第一个想法是创意会话和流程,但仍然可以做的更多。

项目需求文档是什么样子的?在一个明确需求的项目中,它可能有很多页的详细说明,Mindmap并没有消除团队拥有所有这些细节的需求,但是需求文档并不是最好的通信工具。

3、项目指示板

指示板的主要用途是用于项目报告,而企业项目管理工具的最大优点是它们能够实现可定制的报告,因此指示板可以反映对涉众重要的内容。

即使团队成员没有相同的指示板访问权限,仍然可以与它们共享数据,要么打印成PDF,然后以电子方式共享,要么接受屏幕截屏并分享图像。

4、照片

照片和截图可以用很多不同的方式使用,即使是在那些输出不是特别上相的项目上。

社交网络对工作方式的另外一个影响是,人们想要更多地与项目背后的个性联系在一起,在工作坊或网站上分享你的团队照片,真的可以让这个项目看起来更真实,这反过来又能提高参与度。

5、视频

如同Jing和Loom这样的工具可以很容易地捕捉和分享短视频,这些都是比较成熟的沟通工具,可以帮助别人知道他们真正想要的是什么,或者快速地展示一个交付物是如何到来的,Lumen5是一个用于为通信创建视频的简单工具,具体教程可参见:https://www.girlsguidetopm.com ... men5/

在简报中包含一个视频链接:如果他们不感兴趣的话,不会点击,但是肯定还是有一些人会去点击查看的。

无论选择哪种提高项目的沟通方式的办法,最重要的是需要考虑这种方法是否对当前的环境有意义?








为什么要转向视觉思维?

当交流方式和视觉上有一个根本性的转变,无论在项目管理软件中充分利用数据可视化工具,还是拿出智能手机捕捉一个团队在一天中发生的事情的视频,重要的是能够与视觉焦点与分享的项目工作。

视觉传播的趋势在这里,就像项目团队采用了“公司”的社交媒体工具一样,项目团队需要采用可视化的思维方式来处理日益增长的期望,即数据也应该被共享。

开发人员与项目管理

不管一个新项目的开始有多么的令人兴奋,开发人员和整个工作团队仍然需要克服许多障碍。随着业务的增长和项目的增加,事情就越容易失控,可能会出现诸多不同的挑战,例如开发人员没有达到预期的目标,被随之而来的工作所淹没最终面临着失败。

针对雄心勃勃的项目开发人员需要关注高质量的工作,并按照计划进行操作,为了确保一切顺利进行,通常会选择一个健壮的、对客户友好的管理系统工具,以划分任务并帮助团队弥合潜在差距,为什么一个可靠的项目管理工具已经成为几乎所有开发者的必备?有以下几个原因:

1、提高团队协作

开发人员使用项目管理软件的一个重要原因是,它最终增加了团队的响应时间和讨论时间,由于开发人员需要关注的事情太多,任何终端都可能对他们的创造力产生破坏性影响,一个好的项目管理工具使团队能够在不打断任何人的情况下,发布“需要知道”的信息,它不仅使团队专注于工作,而且还提高了生产力,并使每个人都处于循环状态,在开发人员、设计师、项目经理和其他团队成员之间建立清晰而间接的沟通是至关重要的,可以避免任何误解和分歧,它使协作在一个地方一直保持并且能看到所有项目相关的信息。

2、与客户直接沟通

虽然项目经理通常充当客户和团队之间的沟通桥梁,但从一开始就让客户参与到项目中似乎是最佳的解决方案,项目管理工具使客户能够看到开发人员和其他团队成员正在工作并提供反馈,如果有一些敏感信息应该保存在团队中,那么它也很容易被隐藏掉,通过这种方式,开发人员和团队的其他成员与客户保持健康和简单的协作与沟通,而不会让客户感到不舒服和不满意,因此不断交流和保持对客户需求信息的定期更新是很重要的。

3、成功的时间追踪

客户主要对最终产品感兴趣,并且不太在意花费在项目开发上的时间,建议开发人员使用最好的项目管理工具,以便为需要额外工作的情况腾出更多的时间,特别是如果客户要求修改和更改,他们需要跟踪所有的支付,协作工具会自动地存储时间记录,这是一个很好的代替时间表和完美的Timesaver,这也证明了在整个过程中花费的时间,并使客户对团队的工作有重要的了解。

4、发票管理更容易

由于在大型项目上工作需要不断的资金流动,所以账单过程应该是快速而简单的,开发人员有时会对支付负责,因为他们需要快速高效的运用。

项目管理工具提供了一个开发项目的发票时间记录的机会,并根据工作类型、任务或项目等不同的类型对它们进行分组,这使得客户更容易在几次点击中查看发票并完成付款,此外,它还能使它们保持良好的组织,并使开发人员能够跟踪整个开发过程。

5、分类复杂的任务

当开始一个项目时,许多开发人员不得不面对它不那么吸引人的部分——项目规划,多个任务需要完成,他们需要一种方法来持续地组织他们的工作,大多数项目管理工具为每个项目都有一个列,根据给定的项目和类别,可以创建不同的任务组,例如:

特性
产品
优先级
复杂性
进度

这样,工作流就变得易于管理以及更加直接,程序员使用项目管理工具的另一个好处是,它在项目时间线报告中概述了所有项目及其任务,帮助开发人员追踪最繁忙的日期,并相应地避免它们。

使用项目管理工具,可以让团队能够分清主次缓急,在的时间点和预算中交付最好的结果,并在让程序员在下一个开发周期更容易地进行开发拥有一个高效的开发工具对实现这一目标有很大的帮助。

小数以前给大家分享过相关的工具,具体可看:

7大ChatOps&5种团队协作工具助力DevOps实践

初伏天,热出5种DevOps事件管理工具

原文作者:The Practical Developer

原文链接:https://www.tuicool.com/articles/RBjYBzY 查看全部
项目管理一直都是项目经理所需要掌握的必备技能,它可以有效的进行整合,以达到高效、高质、低成本的完成企业内部各项工作或项目的目的。近来让项目管理可视化是大家一致在探讨的问题,数人云今天给大家带来的文章将阐述为什么项目管理可视化的重要性,同时开发人员熟练使用项目管理工具可以让其在整个开发生命周期中更好地掌握项目进度。

项目经理与项目管理

可视化项目管理是使用图形、图片、以及图片来显示项目信息。对于那些偏爱于从视觉上获取信息的人,通常会对他们的任务列表进行涂鸦或将其绘制成列表,而那些喜欢创建列表的人则会选择一个有序的任务列表,现在可以看到的是,项目管理工具在满足这两种偏好方面越来越好,并且使得与需要它的人直观地分享信息变得更加容易,如此同时,通过简单的图形可以让其他人更容易掌握自己复杂的想法。

可视化的重要性是什么?

与文字段落相比,在图表上交流复杂的结构或共享数据点要容易很多,从古至今一直如此,今天,技术可以让我们更容易提取所需的数据并且以一种简单易懂的方式呈现出来,方便大家查阅以及阐述想法。


1.png



Buzzsumo报道称,视频内容的平均股价上涨了近一倍,而早在2010年,《福布斯》就报道称,视频是高管们的关键信息来源,凸显了以在线视频格式观看业务内容的上升趋势。

基本上,网络正从一个基于文本的环境转变为更多的视觉、图形和视频的环境,这也影响了工作场所的交流。

这对项目经理意味着什么?

与项目经理一起工作的团队成员在其他地方看到不同格式的信息,例如,视频在Facebook上的兴起意味着现在比以前更多的人在消费视频内容,更习惯看到它并搜索它,人们把他们的沟通喜好带到了工作场所。

如果项目的赞助者可以下载一段三分钟关于经济状况的视频,或者是一项复杂的健康研究,他们就会期待同样的信息——提炼成容易消费的数据块——用于他们的项目。

如何在项目中加入视觉传达?

无论是将困难的过程分解成易于遵循的过程图,还是在可视化计划中显示项目进展,都可以通过一些方法共享项目性能数据,从而使您的射中更容易理解消息。

以下是5种“做”视觉项目管理沟通的方法:

1、工作视觉规划工具

无论团队使用的是敏捷方法还是基于瀑布式的方法(或两者混合),都可以考虑您可以与团队成员共享项目进度的方法。

许多项目经理从Gantt图中进行复制和粘贴,并将它们列在项目报告当中,又或许是在一个有日期的表中,考虑一下显示Gantt的卷图版本,或者创建一个具有里程碑跟踪的可视化计划,它只显示关键的里程碑,这是一种比日期列表更有效的共享项目进展的方式。 可以对看板做同样的事情:创建一个显示主要项目步骤和进度的高级版,并在进度报告中包含一个快照。

2、Mindmaps

Mindmapping软件的第一个想法是创意会话和流程,但仍然可以做的更多。

项目需求文档是什么样子的?在一个明确需求的项目中,它可能有很多页的详细说明,Mindmap并没有消除团队拥有所有这些细节的需求,但是需求文档并不是最好的通信工具。

3、项目指示板

指示板的主要用途是用于项目报告,而企业项目管理工具的最大优点是它们能够实现可定制的报告,因此指示板可以反映对涉众重要的内容。

即使团队成员没有相同的指示板访问权限,仍然可以与它们共享数据,要么打印成PDF,然后以电子方式共享,要么接受屏幕截屏并分享图像。

4、照片

照片和截图可以用很多不同的方式使用,即使是在那些输出不是特别上相的项目上。

社交网络对工作方式的另外一个影响是,人们想要更多地与项目背后的个性联系在一起,在工作坊或网站上分享你的团队照片,真的可以让这个项目看起来更真实,这反过来又能提高参与度。

5、视频

如同Jing和Loom这样的工具可以很容易地捕捉和分享短视频,这些都是比较成熟的沟通工具,可以帮助别人知道他们真正想要的是什么,或者快速地展示一个交付物是如何到来的,Lumen5是一个用于为通信创建视频的简单工具,具体教程可参见:https://www.girlsguidetopm.com ... men5/

在简报中包含一个视频链接:如果他们不感兴趣的话,不会点击,但是肯定还是有一些人会去点击查看的。

无论选择哪种提高项目的沟通方式的办法,最重要的是需要考虑这种方法是否对当前的环境有意义?


2.png



为什么要转向视觉思维?

当交流方式和视觉上有一个根本性的转变,无论在项目管理软件中充分利用数据可视化工具,还是拿出智能手机捕捉一个团队在一天中发生的事情的视频,重要的是能够与视觉焦点与分享的项目工作。

视觉传播的趋势在这里,就像项目团队采用了“公司”的社交媒体工具一样,项目团队需要采用可视化的思维方式来处理日益增长的期望,即数据也应该被共享。

开发人员与项目管理

不管一个新项目的开始有多么的令人兴奋,开发人员和整个工作团队仍然需要克服许多障碍。随着业务的增长和项目的增加,事情就越容易失控,可能会出现诸多不同的挑战,例如开发人员没有达到预期的目标,被随之而来的工作所淹没最终面临着失败。

针对雄心勃勃的项目开发人员需要关注高质量的工作,并按照计划进行操作,为了确保一切顺利进行,通常会选择一个健壮的、对客户友好的管理系统工具,以划分任务并帮助团队弥合潜在差距,为什么一个可靠的项目管理工具已经成为几乎所有开发者的必备?有以下几个原因:

1、提高团队协作

开发人员使用项目管理软件的一个重要原因是,它最终增加了团队的响应时间和讨论时间,由于开发人员需要关注的事情太多,任何终端都可能对他们的创造力产生破坏性影响,一个好的项目管理工具使团队能够在不打断任何人的情况下,发布“需要知道”的信息,它不仅使团队专注于工作,而且还提高了生产力,并使每个人都处于循环状态,在开发人员、设计师、项目经理和其他团队成员之间建立清晰而间接的沟通是至关重要的,可以避免任何误解和分歧,它使协作在一个地方一直保持并且能看到所有项目相关的信息。

2、与客户直接沟通

虽然项目经理通常充当客户和团队之间的沟通桥梁,但从一开始就让客户参与到项目中似乎是最佳的解决方案,项目管理工具使客户能够看到开发人员和其他团队成员正在工作并提供反馈,如果有一些敏感信息应该保存在团队中,那么它也很容易被隐藏掉,通过这种方式,开发人员和团队的其他成员与客户保持健康和简单的协作与沟通,而不会让客户感到不舒服和不满意,因此不断交流和保持对客户需求信息的定期更新是很重要的。

3、成功的时间追踪

客户主要对最终产品感兴趣,并且不太在意花费在项目开发上的时间,建议开发人员使用最好的项目管理工具,以便为需要额外工作的情况腾出更多的时间,特别是如果客户要求修改和更改,他们需要跟踪所有的支付,协作工具会自动地存储时间记录,这是一个很好的代替时间表和完美的Timesaver,这也证明了在整个过程中花费的时间,并使客户对团队的工作有重要的了解。

4、发票管理更容易

由于在大型项目上工作需要不断的资金流动,所以账单过程应该是快速而简单的,开发人员有时会对支付负责,因为他们需要快速高效的运用。

项目管理工具提供了一个开发项目的发票时间记录的机会,并根据工作类型、任务或项目等不同的类型对它们进行分组,这使得客户更容易在几次点击中查看发票并完成付款,此外,它还能使它们保持良好的组织,并使开发人员能够跟踪整个开发过程。

5、分类复杂的任务

当开始一个项目时,许多开发人员不得不面对它不那么吸引人的部分——项目规划,多个任务需要完成,他们需要一种方法来持续地组织他们的工作,大多数项目管理工具为每个项目都有一个列,根据给定的项目和类别,可以创建不同的任务组,例如:

特性
产品
优先级
复杂性
进度

这样,工作流就变得易于管理以及更加直接,程序员使用项目管理工具的另一个好处是,它在项目时间线报告中概述了所有项目及其任务,帮助开发人员追踪最繁忙的日期,并相应地避免它们。

使用项目管理工具,可以让团队能够分清主次缓急,在的时间点和预算中交付最好的结果,并在让程序员在下一个开发周期更容易地进行开发拥有一个高效的开发工具对实现这一目标有很大的帮助。

小数以前给大家分享过相关的工具,具体可看:

7大ChatOps&5种团队协作工具助力DevOps实践

初伏天,热出5种DevOps事件管理工具

原文作者:The Practical Developer

原文链接:https://www.tuicool.com/articles/RBjYBzY

你的编程语言价值几何?2017年15种薪资最高编程语言出炉

杨y 发表了文章 • 0 个评论 • 114 次浏览 • 2017-11-28 19:03 • 来自相关话题

最近知乎上有一个《为什么很少看到程序员炫富?》的话题火了,看来大家都认同程序员=高薪这种逻辑关系,数人云今天翻阅外网文章看到了一篇2017年15种高薪编程语言,不看不知道,看了吓一跳,虽然国外和国内还是有一些差距的,但是这也表明这些编程语言的薪资报酬上限仍然很高,来看看你所用的语言薪资是多少吧!

2017年薪资最高的15种编程语言

在经济领域和社会领域,科技一直占据着主导的地位,它为数百万人提供了就业的机会,有的人甚至想跨领域去学习技术算计科学、编程以及其他与技术相关的工作,相关的企业也为了寻找到合适的员工提供了相当丰厚的报酬,下列举的这些编程语言即可见一斑:

GO

GO语言的薪资平均在11万美元/年以上,近年来已经高居榜首,09年创建于谷歌的开源开发平台,后如Uber、SondCloud、Netflix、Google和Dropbox都利用了GO语言的元素,实现了内部和基础设施功能。

Scala

熟悉Scala的开发者每年可以获得高达11万美元的收入,不过这还要取决于经验和专业知识,与Java的互通性是Scala的一个关键的特性,因此熟悉这两种开发语言的开发者在寻找工作时会在竞争中占据优势。

Objective-C

Objective-C不仅是一问世时间最久开发者最熟悉的编程语言之一,同时它也非常的赚钱,每年的薪水约在10万美元到 11万美元之间。

CoffeeScript

由于CoffeeScript的可读性和精简性以及能完美转换成JavaScript,使得它在业界广受欢迎,拥有CoffeeScript专业知识的开发者美元收入高达105,000美元。

R

作为一门主要应用于统计计算和图形的开源语言,随着数据驱动分析和预测建模深入到各个行业,R语言也一路水涨船高,平均年薪为10万美元。

TypeScript

TypeScript是一门Microsoft维护的开源编程语言,用于在客户端和服务器端开发JavaScript应用,若能熟练地运用它,大约可以获得10万美元每年的薪资。

SQL

自1974年以来,SQL在四十多年间为成千上万的程序员和数据管理提供了解决方案,如Google、Helix、IBM、Amazon、Microsoft、Oracle等技术巨头至今仍然在继续运用SQL并为其提供了7万到9万美元的年薪。

Java

Java是世界上最流行的编程语言之一,作为客户端—服务器端Web应用程序领域的主要参与者,大约有900万开发人员在使用着Java,如果你是一个Java领域的专家,大约可以获得11.7W美元/年的薪水,普通的Java开发者或许拿不到这么多,但也在7到9万美元之间。

Python

作为一门广受欢迎的通用编程语言,Python的代码可读性和语法的简易性相比于C++或Java可谓是更进一步,Python专家的期望薪水接近9.9万美元。

JavaScript

尽管在过去的几年中,JavaScript的流行度在HTML和CSS的精简版本中大幅度下降,但是大多数现代网站仍然在使用它进行着各种交互,拥有其专业知识的开发者报酬最高达11万美元。

C++

C仍然是一门很重要的编程语言,其通用、快速备受欢迎,哪些在C方面保持专业水平的人可能会拿到年薪9万到10万美元之间的职位。

C#

作为微软.NET框架计划的一个产品,C#仍然是面向对象编程的主流解决方案,它的语法与C++和Java非常相似,但那些具有C#专业知识的程序员每年可以赚到10.7万美元。

Perl

由于Perl的功能强大型和可靠性,它被称为脚本语言中的“瑞士军刀”主要用于管理系统、网络编程、财务和图形用户界面,熟悉Perl语言的人年薪差不多高达11万美元。

PHP

PHP是一门占据着主导地位的编程语言,针对服务器端的Web开发,依赖于C和C++,熟悉这三门编程语言的开发人员能够很容易的就找到一门专注于PHP的高薪工作,薪水可能达到12万美元左右。

IOS/Sift

Swift是近来年发布的最重要的编程语言之一了,苹果将其运用于现代操作系统,如Mac OS和IOS,从事Swift开发的相关人员平均年薪通常高达8万美元,某些高端职位的年薪可能高达12万美元。

当然,以上这些数据报告都是来源于国外,国内与其还有着不少的差距,同时经验与知识度也是衡量一个职位薪水的重要标准,但仍然可以看见其实上述每种语言都有很大的上升空间,需要不断地学习进取,充实自身。 查看全部

微信图片_20171127160629.jpg



最近知乎上有一个《为什么很少看到程序员炫富?》的话题火了,看来大家都认同程序员=高薪这种逻辑关系,数人云今天翻阅外网文章看到了一篇2017年15种高薪编程语言,不看不知道,看了吓一跳,虽然国外和国内还是有一些差距的,但是这也表明这些编程语言的薪资报酬上限仍然很高,来看看你所用的语言薪资是多少吧!

2017年薪资最高的15种编程语言

在经济领域和社会领域,科技一直占据着主导的地位,它为数百万人提供了就业的机会,有的人甚至想跨领域去学习技术算计科学、编程以及其他与技术相关的工作,相关的企业也为了寻找到合适的员工提供了相当丰厚的报酬,下列举的这些编程语言即可见一斑:

GO

GO语言的薪资平均在11万美元/年以上,近年来已经高居榜首,09年创建于谷歌的开源开发平台,后如Uber、SondCloud、Netflix、Google和Dropbox都利用了GO语言的元素,实现了内部和基础设施功能。

Scala

熟悉Scala的开发者每年可以获得高达11万美元的收入,不过这还要取决于经验和专业知识,与Java的互通性是Scala的一个关键的特性,因此熟悉这两种开发语言的开发者在寻找工作时会在竞争中占据优势。

Objective-C

Objective-C不仅是一问世时间最久开发者最熟悉的编程语言之一,同时它也非常的赚钱,每年的薪水约在10万美元到 11万美元之间。

CoffeeScript

由于CoffeeScript的可读性和精简性以及能完美转换成JavaScript,使得它在业界广受欢迎,拥有CoffeeScript专业知识的开发者美元收入高达105,000美元。

R

作为一门主要应用于统计计算和图形的开源语言,随着数据驱动分析和预测建模深入到各个行业,R语言也一路水涨船高,平均年薪为10万美元。

TypeScript

TypeScript是一门Microsoft维护的开源编程语言,用于在客户端和服务器端开发JavaScript应用,若能熟练地运用它,大约可以获得10万美元每年的薪资。

SQL

自1974年以来,SQL在四十多年间为成千上万的程序员和数据管理提供了解决方案,如Google、Helix、IBM、Amazon、Microsoft、Oracle等技术巨头至今仍然在继续运用SQL并为其提供了7万到9万美元的年薪。

Java

Java是世界上最流行的编程语言之一,作为客户端—服务器端Web应用程序领域的主要参与者,大约有900万开发人员在使用着Java,如果你是一个Java领域的专家,大约可以获得11.7W美元/年的薪水,普通的Java开发者或许拿不到这么多,但也在7到9万美元之间。

Python

作为一门广受欢迎的通用编程语言,Python的代码可读性和语法的简易性相比于C++或Java可谓是更进一步,Python专家的期望薪水接近9.9万美元。

JavaScript

尽管在过去的几年中,JavaScript的流行度在HTML和CSS的精简版本中大幅度下降,但是大多数现代网站仍然在使用它进行着各种交互,拥有其专业知识的开发者报酬最高达11万美元。

C++

C仍然是一门很重要的编程语言,其通用、快速备受欢迎,哪些在C方面保持专业水平的人可能会拿到年薪9万到10万美元之间的职位。

C#

作为微软.NET框架计划的一个产品,C#仍然是面向对象编程的主流解决方案,它的语法与C++和Java非常相似,但那些具有C#专业知识的程序员每年可以赚到10.7万美元。

Perl

由于Perl的功能强大型和可靠性,它被称为脚本语言中的“瑞士军刀”主要用于管理系统、网络编程、财务和图形用户界面,熟悉Perl语言的人年薪差不多高达11万美元。

PHP

PHP是一门占据着主导地位的编程语言,针对服务器端的Web开发,依赖于C和C++,熟悉这三门编程语言的开发人员能够很容易的就找到一门专注于PHP的高薪工作,薪水可能达到12万美元左右。

IOS/Sift

Swift是近来年发布的最重要的编程语言之一了,苹果将其运用于现代操作系统,如Mac OS和IOS,从事Swift开发的相关人员平均年薪通常高达8万美元,某些高端职位的年薪可能高达12万美元。

当然,以上这些数据报告都是来源于国外,国内与其还有着不少的差距,同时经验与知识度也是衡量一个职位薪水的重要标准,但仍然可以看见其实上述每种语言都有很大的上升空间,需要不断地学习进取,充实自身。

大会实录|清华徐葳:人工智能让数据中心更好运维

杨y 发表了文章 • 0 个评论 • 128 次浏览 • 2017-11-22 16:59 • 来自相关话题

 
嘉宾介绍:徐葳,清华大学交叉信息研究院助理院长,青年千人学者,博士生导师,UC Berkeley 计算机系 PhD,曾供职于 Google。主要方向为基础架构的监控,日志等,目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。清华大学数据中心运维那点事儿

我(徐葳)显然是个科研人员,同时还管理很多行政事务等,但有些人“命不好”,就是系统管理员的命。所以花了很多时间去管一个IT系统,学院的机房、云平台,基本上夜里大家都睡了,还要登陆上去看看日志,该修点什么就修点什么,我这个人有个毛病,就是看不得机器坏了,看不得什么东西不行,就得马上修好。

清华有系统管理员,就如同我一样都有系统管理员病,很喜欢做系统管理,但他们都是白天上班,因为没有加班费,所以不好意思让人晚上加班,所以晚上一般都由我来管。

这个数据中心做的是人工智能,现在人工智能很热,科研领域清华做的非常前沿,这是最最聪明的应用,但是跑在最最傻的基础架构上。

因为曾经供职于Google,非常想在清华复制一套Google的架构,但这并非一两个人就能开发出来。所以,即便在Google,唯一不能用的地方就是系统运维领域,这是灯下黑,这也是本次讲演的主题叫:“数据中心与智能”。
今天给大家分享几个方面:
首先,数据中心运维,这是和百度合作的一个数据分析的事情,会给大家展示几个有意思的结果。其次,讨论下现在的新架构,Deep Learning深入学习,如何维护这个框架,怎么把数据中心改造成可以进行支持。最后,数据中心现在如此复杂,怎么能再利用一些人工智能的东西放在数据中心里帮助运维。
如何平衡硬件+软件+运维?

首先,这是和百度合作的一件事,百度有很多的机器,有个部门叫硬件运营部,他们收集了很多故障报修,各种产品线,各种不同的产品报修了硬件,硬件运维部就派人去处理一下,大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket,几年内积累了29万个,我们可以帮助它的地方是,到底什么东西坏了,拿出来看看,什么时候报修的,大概什么故障,什么部件坏了,这里有很多结果,但因为时间关系,就不挨个赘述了。

报修了一个故障,多长时间会修?如同百度这样管理非常好的公司,报修之后多长时间会有人去处理?不是说修好它,修了不一定能够修好,但至少是去修了,该换什么就换什么,硬盘报错,坏了,就换一个硬盘。

具体时长看起来会非常奇怪:平均需要42天报完错可以修,中位数的修理时间是6.1天,其中有10%的是140天之后仍然没有修,但是没人修并不代表永远都不要这个东西了,过了200天以后仍然有人去处理它,而并没有忘记。
感觉这个时间过长,到底是因为什么?因为机器太多了?又或者系统管理员太忙了?其实未必。

因为如百度、Google这样的公司,系统架构非常容错,硬件出问题是不可避免的,它坏了,既然能容错,就像四个轱辘掉了一个还能跑,为什么要去修呢?所以逻辑是有一个超级容错的系统,在运维时对故障就没有那么敏感。从好的方面来说,可以省钱,因为一次修一个也得跑一趟,修若干个也得跑一趟,因此还不如一次批量的修。
当然硬件损坏无法避免,是否能降低一些容错的复杂性呢?大家目前越来越多的都在讨论这件事,就是三者的平衡,运维的可靠性、软件的成本、硬件的成本之间的三者平衡,现在越来越重要了。

另外,不管如何运维,运维的系统都是非常重要的,任何运维都不是登到界面上去敲几行命令,然后就派出一一件事,这个都是无法做到的,所以不管如何,系统的运维,从一个地方生成这样配置的操作,从一个地方生成的部署,都很重要。
以上讲的是硬件、软件、运维,这三个部分成本如何平衡,现在这个状态下,尤其是大规模的数据中心,有可能和过去小的企业数据中心不同。基于数人云的Docker管理环境

现在深度学习火了,每个人都想要深度学习的机器。最开始一个人要的时候,没关系,从桌面虚拟机集群拆出两台来,装上GPU,自己去用。现在这样的人多了,装了60几块GPU仍然不够,所以这种集群如何共享这60几块GPU,非常麻烦。

后面做了一个什么事情呢?找数人云做GPU虚拟化,虽然GPU支持虚拟化但太贵所以不买,买的都是消费者级别的GPU,因为便宜。当它不支持虚拟化时联合容器,所以将GPU集群上放上了Docker,又找了数人云,帮助开发一个数人云的管理系统,是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学,因此对它的印象很好。

将来的就是这样的架构,好处是解决了一个问题,即服务封装,DeepLearning这事真的不复杂,如果你玩过,会发现很简单,其实就是找一个开源的软件框架,上面有很多模型,将其下载下来,都是开源的,这些模型甚至都是训练好的,可以跑人脸识别应用,或者跑其他的什么识别应用,虽然没有专业跑的好,但也不会太差。
但它的问题在于是基于框架,尤其在中国,版本不一样,升级版本升级的特别快,随便动一个升级,其他人都烂了,而不同人就要不同的版本,为什么,因为它下的那个模型是基于某个特定版本开发的,在别的版本上跑不出来,所以在这种情况下,大家去到无数多个配置好的镜像和环境,这个场景挺好,Docker、数人云有它的界面,将这个东西配置好,这种Docker配置的这种Docker,只有这个Docker里面用的是那种版本的东西,因为Docker是一层一层的,不用做那么多镜像,只有一点点区别没有关系,那么多借点有一点点区别,占不了那么多空间,好多镜像,各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题,但有一个问题,总得有训练数据,有点什么东西在里面,完成后改了配置等等,这些东西不可能存回到那个镜像里头去,就想那怎么办呢?可能过了两个星期之后还用呢?所以就不上Docker,留着,等两个星期后再说,但两个星期后做别的项目去了,机器就卡在那里,所以这是个问题,存储它的周边结果存在哪里,是个好大的问题。
简单的方法,有OpenStack,集群上500块硬盘总是有的,挂上NFS,每台机器上面有一个Ceph的NFS,把这些东西对接好,想把这个东西存在那个上面保证安全的,关了以后重启时再挂回来,设计了这样一套存储。
那有什么问题呢?DeepLearning的模型也很大,有些人直接在上面跑,本想让它存储一个备份数据用,跑到上面做一下其实还是存在本地。

所以后来自己改造了存储的架构,做了一个开源项目Alluxio,也是伯克利实验室的一个同学做的。

Alluxio缓存非常有用,它还为Ceph和NFS适配了一个接口,还有Hadoop集群,HDFS里面也有几百块盘,将这三种东西适配城了两个借口,适合放在Docker里面,也适合放在Hadoop里面,且它加了些缓存,这样用机器人内存吸收了很多流量,上图就是大概的基本架构。

HDFS也可以支持,同时也能顺便支持Hadoop,但是如果有一些大的文件,愿意用HDFS的,就用HDFS。

有写机器内存还蛮多的,就是当年趁内存时买了一些内存,还是很有用的,可以将内容缓存住。分布式内存很有意思。用人工智能帮助数据中心运维

最后说一下很多做DeepLearning的程序,这张图片解释了一个词“复杂”,OpenStack觉得自己很干净,为什么?拿个笔都能画出来,但是这张图很复杂,复杂的原因不光是因为有这么多图,凡是看见的都是数据库,数据库是一个持久性的状态,每个组件里都有自己持久的状态,那如怎么保证一致?讨论了这么久分布式系统的一致性,它一旦跨了组件,尤其是跨了开源项目,谁也不会再说这件事。

但若组件坏了,里面还有一个复杂的结构,它一层一层的封装起来,所以什么东西坏了,你可能根本不知道,没坏的时候什么都特别好,但坏了就会很麻烦。
我是个很好的系统管理员,这点特别有信心,但是搞不定这个,因为我不是每天都在配这个,记不得这些东西到底在什么地方,随便查一个什么东西,后面的参数那么长,咱们记不住,但别人天天都在做当然可以记住。

那么,如何能动呢?我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库,在里面找一些相关的事情,这是纯从样子上找到的,跟语义没有关系。比如ID长那样,那个ID就是ID,IP地址就是IP地址,将这些东西都找在一起,把这些关联性插在一起,就能生成知识图。

另外,为什么三台机器一起坏了,有可能用户只看到一台机器坏了,但其实另外两台也是如此,因为它坏的原因是一个物理机,要坏肯定是三台一起坏,所以都可以找到系统里的一些东西,这有多少个节点?看这个系统看三天,120台物理机不算大,待该有60多个存储的借点,120多个虚拟机的节点,大概出来的结果是几千万个状态,如上图所示,所以可以想象为什么这东西老坏。

最后总结一下,运维是个什么样的过程?刚才说到DevOps,过去的系统管理员如何适应DevOps是一个非常大的挑战,因为DevOps,运维的人是靠开发程序来自动化运维数据中心的,这是必然的趋势,听起来都对。但DevOps推广起来非常难。
DevOps想要推行,一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方,基本的意思是,预生几个命令行,别说那么多分布式的东西,感觉就是几个配置文件,点点什么东西,这个接口怎么配置,是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录,后台回复“1116”即可下载本次大会的PPT资料。 查看全部
 
嘉宾介绍:徐葳,清华大学交叉信息研究院助理院长,青年千人学者,博士生导师,UC Berkeley 计算机系 PhD,曾供职于 Google。主要方向为基础架构的监控,日志等,目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。清华大学数据中心运维那点事儿

我(徐葳)显然是个科研人员,同时还管理很多行政事务等,但有些人“命不好”,就是系统管理员的命。所以花了很多时间去管一个IT系统,学院的机房、云平台,基本上夜里大家都睡了,还要登陆上去看看日志,该修点什么就修点什么,我这个人有个毛病,就是看不得机器坏了,看不得什么东西不行,就得马上修好。

清华有系统管理员,就如同我一样都有系统管理员病,很喜欢做系统管理,但他们都是白天上班,因为没有加班费,所以不好意思让人晚上加班,所以晚上一般都由我来管。

这个数据中心做的是人工智能,现在人工智能很热,科研领域清华做的非常前沿,这是最最聪明的应用,但是跑在最最傻的基础架构上。

因为曾经供职于Google,非常想在清华复制一套Google的架构,但这并非一两个人就能开发出来。所以,即便在Google,唯一不能用的地方就是系统运维领域,这是灯下黑,这也是本次讲演的主题叫:“数据中心与智能”。
今天给大家分享几个方面:
  • 首先,数据中心运维,这是和百度合作的一个数据分析的事情,会给大家展示几个有意思的结果。
  • 其次,讨论下现在的新架构,Deep Learning深入学习,如何维护这个框架,怎么把数据中心改造成可以进行支持。
  • 最后,数据中心现在如此复杂,怎么能再利用一些人工智能的东西放在数据中心里帮助运维。

如何平衡硬件+软件+运维?

首先,这是和百度合作的一件事,百度有很多的机器,有个部门叫硬件运营部,他们收集了很多故障报修,各种产品线,各种不同的产品报修了硬件,硬件运维部就派人去处理一下,大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket,几年内积累了29万个,我们可以帮助它的地方是,到底什么东西坏了,拿出来看看,什么时候报修的,大概什么故障,什么部件坏了,这里有很多结果,但因为时间关系,就不挨个赘述了。

报修了一个故障,多长时间会修?如同百度这样管理非常好的公司,报修之后多长时间会有人去处理?不是说修好它,修了不一定能够修好,但至少是去修了,该换什么就换什么,硬盘报错,坏了,就换一个硬盘。

具体时长看起来会非常奇怪:平均需要42天报完错可以修,中位数的修理时间是6.1天,其中有10%的是140天之后仍然没有修,但是没人修并不代表永远都不要这个东西了,过了200天以后仍然有人去处理它,而并没有忘记。
感觉这个时间过长,到底是因为什么?因为机器太多了?又或者系统管理员太忙了?其实未必。

因为如百度、Google这样的公司,系统架构非常容错,硬件出问题是不可避免的,它坏了,既然能容错,就像四个轱辘掉了一个还能跑,为什么要去修呢?所以逻辑是有一个超级容错的系统,在运维时对故障就没有那么敏感。从好的方面来说,可以省钱,因为一次修一个也得跑一趟,修若干个也得跑一趟,因此还不如一次批量的修。
当然硬件损坏无法避免,是否能降低一些容错的复杂性呢?大家目前越来越多的都在讨论这件事,就是三者的平衡,运维的可靠性、软件的成本、硬件的成本之间的三者平衡,现在越来越重要了。

另外,不管如何运维,运维的系统都是非常重要的,任何运维都不是登到界面上去敲几行命令,然后就派出一一件事,这个都是无法做到的,所以不管如何,系统的运维,从一个地方生成这样配置的操作,从一个地方生成的部署,都很重要。
以上讲的是硬件、软件、运维,这三个部分成本如何平衡,现在这个状态下,尤其是大规模的数据中心,有可能和过去小的企业数据中心不同。基于数人云的Docker管理环境

现在深度学习火了,每个人都想要深度学习的机器。最开始一个人要的时候,没关系,从桌面虚拟机集群拆出两台来,装上GPU,自己去用。现在这样的人多了,装了60几块GPU仍然不够,所以这种集群如何共享这60几块GPU,非常麻烦。

后面做了一个什么事情呢?找数人云做GPU虚拟化,虽然GPU支持虚拟化但太贵所以不买,买的都是消费者级别的GPU,因为便宜。当它不支持虚拟化时联合容器,所以将GPU集群上放上了Docker,又找了数人云,帮助开发一个数人云的管理系统,是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学,因此对它的印象很好。

将来的就是这样的架构,好处是解决了一个问题,即服务封装,DeepLearning这事真的不复杂,如果你玩过,会发现很简单,其实就是找一个开源的软件框架,上面有很多模型,将其下载下来,都是开源的,这些模型甚至都是训练好的,可以跑人脸识别应用,或者跑其他的什么识别应用,虽然没有专业跑的好,但也不会太差。
但它的问题在于是基于框架,尤其在中国,版本不一样,升级版本升级的特别快,随便动一个升级,其他人都烂了,而不同人就要不同的版本,为什么,因为它下的那个模型是基于某个特定版本开发的,在别的版本上跑不出来,所以在这种情况下,大家去到无数多个配置好的镜像和环境,这个场景挺好,Docker、数人云有它的界面,将这个东西配置好,这种Docker配置的这种Docker,只有这个Docker里面用的是那种版本的东西,因为Docker是一层一层的,不用做那么多镜像,只有一点点区别没有关系,那么多借点有一点点区别,占不了那么多空间,好多镜像,各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题,但有一个问题,总得有训练数据,有点什么东西在里面,完成后改了配置等等,这些东西不可能存回到那个镜像里头去,就想那怎么办呢?可能过了两个星期之后还用呢?所以就不上Docker,留着,等两个星期后再说,但两个星期后做别的项目去了,机器就卡在那里,所以这是个问题,存储它的周边结果存在哪里,是个好大的问题。
简单的方法,有OpenStack,集群上500块硬盘总是有的,挂上NFS,每台机器上面有一个Ceph的NFS,把这些东西对接好,想把这个东西存在那个上面保证安全的,关了以后重启时再挂回来,设计了这样一套存储。
那有什么问题呢?DeepLearning的模型也很大,有些人直接在上面跑,本想让它存储一个备份数据用,跑到上面做一下其实还是存在本地。

所以后来自己改造了存储的架构,做了一个开源项目Alluxio,也是伯克利实验室的一个同学做的。

Alluxio缓存非常有用,它还为Ceph和NFS适配了一个接口,还有Hadoop集群,HDFS里面也有几百块盘,将这三种东西适配城了两个借口,适合放在Docker里面,也适合放在Hadoop里面,且它加了些缓存,这样用机器人内存吸收了很多流量,上图就是大概的基本架构。

HDFS也可以支持,同时也能顺便支持Hadoop,但是如果有一些大的文件,愿意用HDFS的,就用HDFS。

有写机器内存还蛮多的,就是当年趁内存时买了一些内存,还是很有用的,可以将内容缓存住。分布式内存很有意思。用人工智能帮助数据中心运维

最后说一下很多做DeepLearning的程序,这张图片解释了一个词“复杂”,OpenStack觉得自己很干净,为什么?拿个笔都能画出来,但是这张图很复杂,复杂的原因不光是因为有这么多图,凡是看见的都是数据库,数据库是一个持久性的状态,每个组件里都有自己持久的状态,那如怎么保证一致?讨论了这么久分布式系统的一致性,它一旦跨了组件,尤其是跨了开源项目,谁也不会再说这件事。

但若组件坏了,里面还有一个复杂的结构,它一层一层的封装起来,所以什么东西坏了,你可能根本不知道,没坏的时候什么都特别好,但坏了就会很麻烦。
我是个很好的系统管理员,这点特别有信心,但是搞不定这个,因为我不是每天都在配这个,记不得这些东西到底在什么地方,随便查一个什么东西,后面的参数那么长,咱们记不住,但别人天天都在做当然可以记住。

那么,如何能动呢?我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库,在里面找一些相关的事情,这是纯从样子上找到的,跟语义没有关系。比如ID长那样,那个ID就是ID,IP地址就是IP地址,将这些东西都找在一起,把这些关联性插在一起,就能生成知识图。

另外,为什么三台机器一起坏了,有可能用户只看到一台机器坏了,但其实另外两台也是如此,因为它坏的原因是一个物理机,要坏肯定是三台一起坏,所以都可以找到系统里的一些东西,这有多少个节点?看这个系统看三天,120台物理机不算大,待该有60多个存储的借点,120多个虚拟机的节点,大概出来的结果是几千万个状态,如上图所示,所以可以想象为什么这东西老坏。

最后总结一下,运维是个什么样的过程?刚才说到DevOps,过去的系统管理员如何适应DevOps是一个非常大的挑战,因为DevOps,运维的人是靠开发程序来自动化运维数据中心的,这是必然的趋势,听起来都对。但DevOps推广起来非常难。
DevOps想要推行,一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方,基本的意思是,预生几个命令行,别说那么多分布式的东西,感觉就是几个配置文件,点点什么东西,这个接口怎么配置,是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录,后台回复“1116”即可下载本次大会的PPT资料。

微服务架构企业级增强产品:数人云推出统一配置中心Hawk

杨y 发表了文章 • 0 个评论 • 148 次浏览 • 2017-11-22 16:58 • 来自相关话题

11月16日,数人云在PaaS Innovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企业对微服务应用的管理需求日益强烈,微服务也成为云计算原生应用的标准开发框架,是落地敏捷开发和部署的关键。如今,EAMS产品家族又多了一位核心成员——数人云统一配置中心Hawk。

互联网企业和传统金融等行业具有业务配置复杂,配置数据量大,配置容易出错等特点,如何能将配置数据与程序包解耦,避免对环境的依赖成为一大难点。特别是引入微服务后,业务配置数量急剧增加,出错概率也同步增加,如果能统一管控,支持多环境管理成为运维的一大难点和痛点。

基于微服务理念打造的分布式统一配置中心Hawk支持多种类型配置如Spring Cloud、Dubbo、Kubernetes Configmap、Logback、Linux Environment等等,具有完善的配置管理流程、配置实时推送、支持多集群多环境、多版本控制,更提供配置细力度的管理如灰度管理、任意版本重置等丰富功能。整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及降低业务对于平台的耦合。相应的管理流程也规范了配置的使用和降低因为配置带来的发布错误等。

Hawk的主体架构








在功能方面,数人云分布式统一调度平台Hawk具备完善的企业级功能:

配置流程管理:完善的配置流程管理,确保配置下发前必须获得确认和授权。
认证与授权:提供 LDAP 集成,以及多角色权限管理。
支持操作审计:确保配置操作有据可查。
支持多种配置文件:支持Spring Cloud Config、Dubbo、Logback、Linux Environment、Nginx、Tomcat等等,并持续增加中。
支持Spring Cloud服务治理配置和管控:支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。
无缝集成 Kubernetes 的 Configmap 以及 Secrets:无缝集成 Kubernetes 的 Configmap 以及 Secrets 的配置管理,并提供增强的企业管理流程。
支持配置实时推送以及实时生效:配置变更能触发应用实时生效,避免应用重启来激活配置,从而降低服务中断的风险。
支持多版本管理:支持多版本管理,并支持历史版本的激活。
支持多配置集群、多环境配置。
优美的监控台:提供多维度 Dashboard 以及监控视图,支持配置灰度和回滚。
支持配置灰度和回滚。
支持数据全局备份和恢复:进一步提升配置数据的容灾能力
提供OpenAPI:支持多系统集成的便利手段、支持配置应急预案处理






数人云的轻量级PaaS平台,在容器平台的基础上延伸出丰富的产品线,致力于成为云时代的新PaaS,为客户快速打造互联网应用的系统和架构支持。在开发以及运维层面,分布式统一配置中心Hawk是EAMS体系的进一步增强。据悉,数人云EAMS体系下,一系列开发管理框架以及智能管理工具尚在持续研发中,以期帮助客户降低运维难度和复杂度,快速应对业务迭代,帮助客户构建敏捷IT能力。 查看全部

1.png



11月16日,数人云在PaaS Innovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企业对微服务应用的管理需求日益强烈,微服务也成为云计算原生应用的标准开发框架,是落地敏捷开发和部署的关键。如今,EAMS产品家族又多了一位核心成员——数人云统一配置中心Hawk。

互联网企业和传统金融等行业具有业务配置复杂,配置数据量大,配置容易出错等特点,如何能将配置数据与程序包解耦,避免对环境的依赖成为一大难点。特别是引入微服务后,业务配置数量急剧增加,出错概率也同步增加,如果能统一管控,支持多环境管理成为运维的一大难点和痛点。

基于微服务理念打造的分布式统一配置中心Hawk支持多种类型配置如Spring Cloud、Dubbo、Kubernetes Configmap、Logback、Linux Environment等等,具有完善的配置管理流程、配置实时推送、支持多集群多环境、多版本控制,更提供配置细力度的管理如灰度管理、任意版本重置等丰富功能。整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及降低业务对于平台的耦合。相应的管理流程也规范了配置的使用和降低因为配置带来的发布错误等。

Hawk的主体架构


2.png



在功能方面,数人云分布式统一调度平台Hawk具备完善的企业级功能:

配置流程管理:完善的配置流程管理,确保配置下发前必须获得确认和授权。
认证与授权:提供 LDAP 集成,以及多角色权限管理。
支持操作审计:确保配置操作有据可查。
支持多种配置文件:支持Spring Cloud Config、Dubbo、Logback、Linux Environment、Nginx、Tomcat等等,并持续增加中。
支持Spring Cloud服务治理配置和管控:支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。
无缝集成 Kubernetes 的 Configmap 以及 Secrets:无缝集成 Kubernetes 的 Configmap 以及 Secrets 的配置管理,并提供增强的企业管理流程。
支持配置实时推送以及实时生效:配置变更能触发应用实时生效,避免应用重启来激活配置,从而降低服务中断的风险。
支持多版本管理:支持多版本管理,并支持历史版本的激活。
支持多配置集群、多环境配置。
优美的监控台:提供多维度 Dashboard 以及监控视图,支持配置灰度和回滚。
支持配置灰度和回滚。
支持数据全局备份和恢复:进一步提升配置数据的容灾能力
提供OpenAPI:支持多系统集成的便利手段、支持配置应急预案处理

3.png


数人云的轻量级PaaS平台,在容器平台的基础上延伸出丰富的产品线,致力于成为云时代的新PaaS,为客户快速打造互联网应用的系统和架构支持。在开发以及运维层面,分布式统一配置中心Hawk是EAMS体系的进一步增强。据悉,数人云EAMS体系下,一系列开发管理框架以及智能管理工具尚在持续研发中,以期帮助客户降低运维难度和复杂度,快速应对业务迭代,帮助客户构建敏捷IT能力。

演讲实录 | 招银云创:容器PaaS正在让开发人员再也看不到IaaS

杨y 发表了文章 • 0 个评论 • 135 次浏览 • 2017-11-20 18:46 • 来自相关话题

嘉宾介绍:陈沙克,招银云创战略研究院总监,从2010年开始从事云计算相关工作,做OpenStack七年有余,目前在招银云创负责PaaS相关工作。此文为陈沙克在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。

招银云创是招商银行的全资子公司,代表招商银行进行科技的输出,致力于将招行30年的经验和技术积累输出给广大金融企业,帮助同业同行快速的金融创新。

容器快速交付提高金融的互联网化

金融行业特性与其他行业在思维方式上有很大不同。

金融是强监管行业,尝试新技术面临监管的要求。那么,强监管下如何跟上变化的需要呢?这里面展开可以有很多故事。在Fintech互联网金融影响下,银行在监管上其实有所放松。其次,银行业有非常严格的安全性要求。由于历史原因,银行内部IT系统非常复杂,通常每家银行都有上百个系统。








中国的银行体系非常庞大,这可能跟金融行业外朋友的感知不同。这些银行包括农村信用社、农村银行、城市商业银行等,他们都有巨大的IT系统托管需求。招银云创就是服务以上这些客户。








随着银行业务的发展,之前系统托管和所服务的客户都是场地托管,系统灵活性不足。但随着互联网以及业务的发展,客户开始提出一些定制化的需求,对银行业务的开展产生巨大挑战。








互联网化的金融IT需求如何应对?客户定制化需求如何满足?金融行业云在互联网金融汹涌来袭的背景下,面临巨大挑战。有同行强调,银行要做金融的互联网,而不能由互联网来主导金融。其实,今天在金融行业的人都应该有这个想法。

招银云创PaaS平台希望将各种行业的应用放在PaaS平台上,帮助企业更快地落地。假如银行有100多个项目同时开发,对于前面提到的大多数银行来讲是不现实的,希望有一个平台能帮助企业实现快速交付。

如何才能做到快速交付?招银云创认为,只有标准化形成规模,才能够将很多东西以一种标准化的形式提供出去,同时也要满足企业未来发展的需求。容器就是一种在标准化和简单化之间找到平衡的技术。








成熟的容器正在让开发人员再也看不到IaaS

现在简单介绍一下招银云创PaaS平台的架构。对于银行来说,金融行业全部应用都是基于JAVA来开发。但现在,新的应用都要求基于Spring Cloud框架来开发,只有用Spring Cloud框架开发,放在PaaS平台上才能体现出优势。容器的管理平台现在已经比较成熟。Kubernetes在新一轮的编排工具大战中胜出,但仅仅一个Kubernetes满足不了金融PaaS的需求,容器周边还需要诸多辅助系统,从而让开发和运维人员更好地使用。







在过去的两个多月,招银云创一直在推动将自己的Spring Cloud应用迁移到PaaS平台。这次迁移团队也积累了很多经验和教训。

首先,配置管理。Spring Cloud的配置管理是用git来管理的。当把应用搬到PaaS平台上时,运维人员会向开发人员提出配置管理的要求,比如要求开发人员对配置要统一管理,不能到处放置配置文件。








开发人员很乐意接受这个建议。以往推PaaS平台时,对开发人员的工作改动量很大。现在,新的PaaS平台开发人员感受到的,不是改动多少代码,而是带来多少便利,以及给出很合理的需求。

招银云创希望在整个Spring Cloud里面配置管理,不仅可以用Git管理,而且开发自己的配置管理中心来完善PaaS平台。

日志管理向来复杂,银行的日志则会更加复杂。原因在于,日志含有大量交易信息,这些信息不仅需要保留,而且要检索。除了系统日志,还包含应用的日志,应用日志量非常庞大,甚至达到每天T级别的日志量,尤其采用微服务后。那么,这些日志应该如何处理呢?













招银云创希望日志管理简单化。对于传统的金融行业来讲,技术没有那么丰富,采用的技术眼花缭乱任何团队想完全Hold住都有压力。招银云创同时希望日志标准化,实现日志的统一管理。招银云创的应用多是自己开发,对应用的日志输出做出要求,这样整个PaaS平台能够真正用起来。

如今,监控已不像以前那么眼花缭乱,Prometheus也实现了一统江湖。加之官方的展示,基本满足招银对监控屏展示的要求。








持续集成则跟开发密切相关。以前在做OpenStack时,经常谈到怎么用OpenStack虚拟机来做持续集成,那个过程很痛苦。因为虚拟机的启动、安装、部署代价非常高,持续时间周期很长。在OpenStack上做开发,如果要跑一两个小时才能出结果,这在传统企业是根本无法接受的。采用容器的CI以后,这种局面得到彻底改观。所有的提交以及镜像发布到测试,可以做到分钟级解决。借助各种内网的源,整个镜像和发布过程很快。







对于新的PaaS平台来说,重点工作之一是通过发布管理去发布。PaaS平台偏运维,在招银云创内部,运维人员能够深切地感受到对自身带来的巨大帮助,以前纯手工的过程全部自动化完成。在过去的两个月,招银云创内部推动PaaS平台积极性最高的也是运维人员,实现了从手工到完全自动化,甚至智能化。招银云创已经做到代码一提交,马上去做镜像,然后推送到发布的一体化流程,这在以往不可想象。在没有容器之前,哪怕采用Spring Cloud开发应用,也无法发挥它的特点。







回到镜像管理,镜像管理能够看到很多方案,但对企业来说,镜像积累到一定程度,变成企业的资产,日后有可能代替电子仓库。云创镜像积累的很好,一些不同版本都能够得到快速满足,实现快速迭代,满足开发需求。







经过两个月PaaS平台的使用,运维人员感触最深的是“开发人员已经看不到IaaS平台了”。为什么这么说?以前开发人员经常要在IaaS平台里面启动各种虚拟机,来进行测试、完善。用了PaaS平台后,开发、发布、交付生产线,都已经不需要关注底层是虚拟机还是物理机,只需要关注一个PaaS平台。





  查看全部

1.png



嘉宾介绍:陈沙克,招银云创战略研究院总监,从2010年开始从事云计算相关工作,做OpenStack七年有余,目前在招银云创负责PaaS相关工作。此文为陈沙克在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。

招银云创是招商银行的全资子公司,代表招商银行进行科技的输出,致力于将招行30年的经验和技术积累输出给广大金融企业,帮助同业同行快速的金融创新。

容器快速交付提高金融的互联网化

金融行业特性与其他行业在思维方式上有很大不同。

金融是强监管行业,尝试新技术面临监管的要求。那么,强监管下如何跟上变化的需要呢?这里面展开可以有很多故事。在Fintech互联网金融影响下,银行在监管上其实有所放松。其次,银行业有非常严格的安全性要求。由于历史原因,银行内部IT系统非常复杂,通常每家银行都有上百个系统。


2.png



中国的银行体系非常庞大,这可能跟金融行业外朋友的感知不同。这些银行包括农村信用社、农村银行、城市商业银行等,他们都有巨大的IT系统托管需求。招银云创就是服务以上这些客户。


3.png



随着银行业务的发展,之前系统托管和所服务的客户都是场地托管,系统灵活性不足。但随着互联网以及业务的发展,客户开始提出一些定制化的需求,对银行业务的开展产生巨大挑战。


4.png



互联网化的金融IT需求如何应对?客户定制化需求如何满足?金融行业云在互联网金融汹涌来袭的背景下,面临巨大挑战。有同行强调,银行要做金融的互联网,而不能由互联网来主导金融。其实,今天在金融行业的人都应该有这个想法。

招银云创PaaS平台希望将各种行业的应用放在PaaS平台上,帮助企业更快地落地。假如银行有100多个项目同时开发,对于前面提到的大多数银行来讲是不现实的,希望有一个平台能帮助企业实现快速交付。

如何才能做到快速交付?招银云创认为,只有标准化形成规模,才能够将很多东西以一种标准化的形式提供出去,同时也要满足企业未来发展的需求。容器就是一种在标准化和简单化之间找到平衡的技术。


5.png



成熟的容器正在让开发人员再也看不到IaaS

现在简单介绍一下招银云创PaaS平台的架构。对于银行来说,金融行业全部应用都是基于JAVA来开发。但现在,新的应用都要求基于Spring Cloud框架来开发,只有用Spring Cloud框架开发,放在PaaS平台上才能体现出优势。容器的管理平台现在已经比较成熟。Kubernetes在新一轮的编排工具大战中胜出,但仅仅一个Kubernetes满足不了金融PaaS的需求,容器周边还需要诸多辅助系统,从而让开发和运维人员更好地使用。

6.png



在过去的两个多月,招银云创一直在推动将自己的Spring Cloud应用迁移到PaaS平台。这次迁移团队也积累了很多经验和教训。

首先,配置管理。Spring Cloud的配置管理是用git来管理的。当把应用搬到PaaS平台上时,运维人员会向开发人员提出配置管理的要求,比如要求开发人员对配置要统一管理,不能到处放置配置文件。


7.png



开发人员很乐意接受这个建议。以往推PaaS平台时,对开发人员的工作改动量很大。现在,新的PaaS平台开发人员感受到的,不是改动多少代码,而是带来多少便利,以及给出很合理的需求。

招银云创希望在整个Spring Cloud里面配置管理,不仅可以用Git管理,而且开发自己的配置管理中心来完善PaaS平台。

日志管理向来复杂,银行的日志则会更加复杂。原因在于,日志含有大量交易信息,这些信息不仅需要保留,而且要检索。除了系统日志,还包含应用的日志,应用日志量非常庞大,甚至达到每天T级别的日志量,尤其采用微服务后。那么,这些日志应该如何处理呢?


8.png


9.png



招银云创希望日志管理简单化。对于传统的金融行业来讲,技术没有那么丰富,采用的技术眼花缭乱任何团队想完全Hold住都有压力。招银云创同时希望日志标准化,实现日志的统一管理。招银云创的应用多是自己开发,对应用的日志输出做出要求,这样整个PaaS平台能够真正用起来。

如今,监控已不像以前那么眼花缭乱,Prometheus也实现了一统江湖。加之官方的展示,基本满足招银对监控屏展示的要求。


10.png



持续集成则跟开发密切相关。以前在做OpenStack时,经常谈到怎么用OpenStack虚拟机来做持续集成,那个过程很痛苦。因为虚拟机的启动、安装、部署代价非常高,持续时间周期很长。在OpenStack上做开发,如果要跑一两个小时才能出结果,这在传统企业是根本无法接受的。采用容器的CI以后,这种局面得到彻底改观。所有的提交以及镜像发布到测试,可以做到分钟级解决。借助各种内网的源,整个镜像和发布过程很快。

11.png



对于新的PaaS平台来说,重点工作之一是通过发布管理去发布。PaaS平台偏运维,在招银云创内部,运维人员能够深切地感受到对自身带来的巨大帮助,以前纯手工的过程全部自动化完成。在过去的两个月,招银云创内部推动PaaS平台积极性最高的也是运维人员,实现了从手工到完全自动化,甚至智能化。招银云创已经做到代码一提交,马上去做镜像,然后推送到发布的一体化流程,这在以往不可想象。在没有容器之前,哪怕采用Spring Cloud开发应用,也无法发挥它的特点。

12.png



回到镜像管理,镜像管理能够看到很多方案,但对企业来说,镜像积累到一定程度,变成企业的资产,日后有可能代替电子仓库。云创镜像积累的很好,一些不同版本都能够得到快速满足,实现快速迭代,满足开发需求。

13.png



经过两个月PaaS平台的使用,运维人员感触最深的是“开发人员已经看不到IaaS平台了”。为什么这么说?以前开发人员经常要在IaaS平台里面启动各种虚拟机,来进行测试、完善。用了PaaS平台后,开发、发布、交付生产线,都已经不需要关注底层是虚拟机还是物理机,只需要关注一个PaaS平台。

14.png

 

大会演讲PPT|数人云王璞:《云计算之PaaS进化:潮涌、碰撞、变革》

杨y 发表了文章 • 0 个评论 • 169 次浏览 • 2017-11-17 16:27 • 来自相关话题

 
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。以下是本次演讲的PPT:
 





























  查看全部

幻灯片1.JPG


幻灯片2.JPG


幻灯片3.JPG


幻灯片4.JPG


幻灯片5.JPG


幻灯片6.JPG


幻灯片8.JPG


幻灯片9.JPG


幻灯片10.JPG


幻灯片11.JPG


幻灯片12.JPG


幻灯片13.JPG


幻灯片14.JPG


幻灯片15.JPG


幻灯片16.JPG


幻灯片17.JPG


 
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。以下是本次演讲的PPT:
 
幻灯片18.JPG


幻灯片19.JPG


幻灯片20.JPG


幻灯片21.JPG


幻灯片22.JPG


幻灯片23.JPG

 

《企业级容器云平台》联盟标准在数人云PaaS Innovation大会发布

杨y 发表了文章 • 0 个评论 • 157 次浏览 • 2017-11-17 16:25 • 来自相关话题

11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation2017,构建灵动新IT”大会在北京成功举办。会上,中国开源云联盟权威发布了企业级容器云平台标准。这是继去年由中国开源云联盟发布首个国内容器白皮书之后,容器技术发展的又一里程碑,标志着容器技术进入成熟稳定落地阶段。

近年来,容器技术逐渐成为继虚拟化技术之后对云计算领域影响深远的技术变革。容器技术从2013年传入国内,为各行业应用云计算提供了新思路,逐渐被研发人员和企业客户所接受。不断成熟的容器技术也对云计算的交付、效率和PaaS平台构建产生着深刻影响。容器已经成为企业落地微服务架构,实现DevOps理念的重要支撑技术。

企业级容器云平台标准权威发布


在发布环节,中国开源云联盟秘书长周平、常务副秘书长杨丽蕴、中国电子技术标准化研究院云计算标准资深专家陈志峰、CNTV运维总监王雷、Intel高级工程师杜永丰、数人云CTO肖德时作为代表共同进行了发布。







中国开源云联盟常务副秘书长杨丽蕴致辞

容器标准的编制由中国开源云联盟牵头并完成,参与单位包括数人云、Intel、央视网、腾讯云、阿里云、华为、联想、网易云等十数家联盟单位。其中数人云为容器工作组组长单位,Intel和CNTV为副组长单位。

容器云平台是Gartner提出来的云管理平台的衍生,共有两方面功能。第一,功能需求,管理容器运行引擎、容器网络,容器编排。第二是非功能需求,可用性,兼容性,安全和易用性,负载优化。容器云平台最终的目标是,应用在云平台上运行时取得最优化的效果。

该标准草案的制定参考了CNCF的理论框架,对容器所涉及的基础设施、运行时环境、容器编排和管理、中间件及DevOps、云管理平台、监控日志追踪等功能组件都定义了清晰的要求。同时,对容器的非功能特性,如性能、兼容性等,也提供相应的规范条款。

标志容器技术进入成熟落地阶段

云计算和 DevOps 都是 “敏捷 IT” 理念下的技术组合,目的在于快速开发并交付业务,而且大规模稳定运行。敏捷的挑战主要来自“高速度”和“低风险”。面对互联网海量用户和海量数据的挑战,未来速度和风险的矛盾将愈演愈烈。其次,互联网和大数据对于传统IT从架构到运维都是“从零到一”的过程,相关经验一直由互联网企业和开源社区掌握。传统 IT 厂商从产品到实践无法提供能落地的支持,企业往往陷入难以起步、一试就错的困境,难以进入通过快速迭代来培养队伍的正向循环。

企业级容器云平台包括三个层面的功能:针对异构资源纳管的容器运行环境,针对微服务和分布式架构支撑的基础架构 PaaS (iPaaS — infrastructure PaaS)和帮助用户快速搭建分布式应用的应用 PaaS (aPaaS — Application PaaS)。

标准草案的发布,旨在顺应国内企业从传统单体架构向微服务架构转变的趋势,满足传统企业业务高速发展的需求。随着开源技术的发展,推动容器技术的成熟稳定和不断落地,敏捷IT有了实现的可能和契机。以Docker为代表的容器技术近几年迎来发展热潮,其轻量化、快速部署、可移植等特性受到追捧。

此次容器云平台标准的推出,标志着容器技术发展日渐成熟,将加速容器云在国内企业的落地。当技术沉淀到标准中,形成容器PaaS的相关标准,企业应用有准可依,技术产业化进程将会大大加速。

关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。

2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

关于WG6容器工作组

WG6—容器工作组由中国电子技术标准化研究院主办,数人云任工作组组长,CNTV,Intel任副组长,包括国电通、国航、去哪儿网、阿里云、VMware、华三等在内的多个单位参与,主要目的是推动容器开源技术在国内的落地;提升容器开源技术在国际容器社区的贡献比例,推动国内用户落地容器技术规范的标准化(包括网络、存储、安全、测试、扩展性、可用性、应用场景等)。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。 查看全部
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation2017,构建灵动新IT”大会在北京成功举办。会上,中国开源云联盟权威发布了企业级容器云平台标准。这是继去年由中国开源云联盟发布首个国内容器白皮书之后,容器技术发展的又一里程碑,标志着容器技术进入成熟稳定落地阶段。

近年来,容器技术逐渐成为继虚拟化技术之后对云计算领域影响深远的技术变革。容器技术从2013年传入国内,为各行业应用云计算提供了新思路,逐渐被研发人员和企业客户所接受。不断成熟的容器技术也对云计算的交付、效率和PaaS平台构建产生着深刻影响。容器已经成为企业落地微服务架构,实现DevOps理念的重要支撑技术。

企业级容器云平台标准权威发布


在发布环节,中国开源云联盟秘书长周平、常务副秘书长杨丽蕴、中国电子技术标准化研究院云计算标准资深专家陈志峰、CNTV运维总监王雷、Intel高级工程师杜永丰、数人云CTO肖德时作为代表共同进行了发布。

QQ图片20171117150919.png



中国开源云联盟常务副秘书长杨丽蕴致辞

容器标准的编制由中国开源云联盟牵头并完成,参与单位包括数人云、Intel、央视网、腾讯云、阿里云、华为、联想、网易云等十数家联盟单位。其中数人云为容器工作组组长单位,Intel和CNTV为副组长单位。

容器云平台是Gartner提出来的云管理平台的衍生,共有两方面功能。第一,功能需求,管理容器运行引擎、容器网络,容器编排。第二是非功能需求,可用性,兼容性,安全和易用性,负载优化。容器云平台最终的目标是,应用在云平台上运行时取得最优化的效果。

该标准草案的制定参考了CNCF的理论框架,对容器所涉及的基础设施、运行时环境、容器编排和管理、中间件及DevOps、云管理平台、监控日志追踪等功能组件都定义了清晰的要求。同时,对容器的非功能特性,如性能、兼容性等,也提供相应的规范条款。

标志容器技术进入成熟落地阶段

云计算和 DevOps 都是 “敏捷 IT” 理念下的技术组合,目的在于快速开发并交付业务,而且大规模稳定运行。敏捷的挑战主要来自“高速度”和“低风险”。面对互联网海量用户和海量数据的挑战,未来速度和风险的矛盾将愈演愈烈。其次,互联网和大数据对于传统IT从架构到运维都是“从零到一”的过程,相关经验一直由互联网企业和开源社区掌握。传统 IT 厂商从产品到实践无法提供能落地的支持,企业往往陷入难以起步、一试就错的困境,难以进入通过快速迭代来培养队伍的正向循环。

企业级容器云平台包括三个层面的功能:针对异构资源纳管的容器运行环境,针对微服务和分布式架构支撑的基础架构 PaaS (iPaaS — infrastructure PaaS)和帮助用户快速搭建分布式应用的应用 PaaS (aPaaS — Application PaaS)。

标准草案的发布,旨在顺应国内企业从传统单体架构向微服务架构转变的趋势,满足传统企业业务高速发展的需求。随着开源技术的发展,推动容器技术的成熟稳定和不断落地,敏捷IT有了实现的可能和契机。以Docker为代表的容器技术近几年迎来发展热潮,其轻量化、快速部署、可移植等特性受到追捧。

此次容器云平台标准的推出,标志着容器技术发展日渐成熟,将加速容器云在国内企业的落地。当技术沉淀到标准中,形成容器PaaS的相关标准,企业应用有准可依,技术产业化进程将会大大加速。

关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。

2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

关于WG6容器工作组

WG6—容器工作组由中国电子技术标准化研究院主办,数人云任工作组组长,CNTV,Intel任副组长,包括国电通、国航、去哪儿网、阿里云、VMware、华三等在内的多个单位参与,主要目的是推动容器开源技术在国内的落地;提升容器开源技术在国际容器社区的贡献比例,推动国内用户落地容器技术规范的标准化(包括网络、存储、安全、测试、扩展性、可用性、应用场景等)。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。

数人云王璞:PaaS蝶变背后是三大技术趋势和三大落地方法

杨y 发表了文章 • 0 个评论 • 120 次浏览 • 2017-11-17 16:24 • 来自相关话题

11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。本次大会由于汇聚了前瞻的PaaS洞察,着眼PaaS技术创新和演进趋势;梳理PaaS落地行业痛点,分享金融标杆客户最佳行业实践、重磅发布企业级容器云平台标准及推导PaaS落地方法,而广受业界瞩目。来自行业的专家、媒体朋友、生态伙伴,以及金融、能源、快消、制造等传统行业客户300余人参加了此次大会。








企业IT变革:轻量化、敏捷化、开源化

数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。传统商业正在被技术深度改变,互联网与传统行业结合的模式探索开始在各行业展开,新金融、新零售、新制造等新的业态不断涌现。在探求数字化转型过程中,无论是技术、人员,还是体制、运营管理,都并非简单的架构调整即可为之,传统业务和互联网场景应用将长期双态并存。

在互联网+重构业务形态的驱动下,传统企业纷纷开拓互联网业务来加大自身的行业竞争优势,这给复杂的响应缓慢的传统IT架构带来严峻挑战。企业IT部门和IT管理者疲于奔命。

王璞在演讲中指出,轻量化、敏捷化和开源化是近年企业IT架构三大最重要的技术演变趋势。






首先,应用容器化、架构微服务化,使得企业级应用变得越来越轻。其次,传统企业开始践行DevOps理念,打造开发运维一体化。将整个从开发到运维的全生命周期整合为统一的流程,研发人员可以专注业务开发本身,无需关注底层技术细节。运维人员大量采用自动化运维平台和工具,运维效率显著提升。由此,敏捷开发和业务敏捷性有了实现的可能。

第三,IT基础设施软件全面拥抱开源。开源技术能够增强企业的自主可控能力,开源可拓展的IT成为企业CIO和其他IT管理者在进行技术选型和新项目建设时的重要选择方向。同时,开源技术更新迭代频繁,也对企业级IT在技术选型上提出了挑战,需要不断在各种技术之间取长补短。

PaaS技术变革:应用容器化、服务网格化、生态行业化

PaaS正在成为云计算市场中增长最快的一极。尽管在大众的印象中,云计算三层之前始终是两家独大,不过最近几年,PaaS表现出强劲的发展势头。据IDC最新的全球半年度公有云服务支出指南,2017年PaaS支出增速五年复合年增长率为32.2%。







PaaS通过技术不断创新积累,深入到企业应用领域,赢得市场,为应用交付、资源管理、运维效率、业务支撑提供了基于新一代IT架构的重要支撑体系。凭借团队在互联网应用架构和企业级IT的丰富经验,并扎根行业,做深做透客户业务特性,王璞在演讲中指出,当前PaaS呈现出应用容器化、服务网格化和行业生态化三大技术趋势。

容器经过4年的迅速发展,已经成为云计算原生应用的标准交付方式,能够对底层基础架构资源实现快速、标准化和更轻量级的管理。其次,微服务将成为云计算原生应用的标准开发架构,传统企业客户对微服务应用的管理需求日益强烈。敏捷开发和部署举步维艰,其中最大的障碍是应用太复杂,以至于单个开发者很难搞懂。微服务架构下,技术选型去中心化,团队可以自由选择合适的技术栈。同时,当需要对技术栈进行升级,面临的风险也小得多。

在以微服务和容器技术为核心的技术转型下,新一代服务网络技术方兴未艾。服务网格技术在云环境下,能够对应用进行更好地管理。开发人员在开发应用时,不必考虑后端管理上的诉求,让开发变得更透明。另外,服务网格技术对后期应用程序的管理维护能够提供更丰富的手段,以及更细粒度的管理。

行业生态化也是PaaS演进的一大重要趋势,企业级IT服务逐步向行业云过渡。数人云通过与生态伙伴合作共同落地私有云、行业云,整合行业内云产业链上IaaS、PaaS和SaaS三层资源,为企业客户提供整体解决方案。王璞强调,在行业云发展的过程中,不仅业务特性突出的SaaS具备行业属性,偏下层的IaaS和PaaS同样具备行业属性,如此更好地实现企业IT资源和服务整合。

PaaS表现出强劲的发展势头,也是行业生态化使然。随着企业应用市场的爆发和成熟,SaaS对PaaS层的要求越来越高,应用要打通、跨层、效率、协作等,这在客观上推动了PaaS体量猛增。

PaaS落地:数人云DataMan OS+EAMS

数人云是国内轻量化PaaS的首倡者,具备PaaS层面丰富的产品线,通过DataMan OS和EAMS两大产品帮助企业客户建立标准化、统一化、模块化的企业级IT体系,落地敏捷IT能力。








DataMan OS是数人云产品的底座,利用容器实现应用标准化交付和统一化运维管理,为用户IT系统带来高可用、弹性伸缩。

EAMS产品基于Spring Cloud微服务开发框架,实现针对微服务应用的统一化服务治理、业务应用模块化,落地敏捷开发,帮助传统企业落地贯穿应用全生命周期的DevOps最佳实践。

“企业要获得敏捷IT,落地DevOps能力,从开发源头上,首先必须进行开发框架的标准化。微服务开发框架解决了应用的复杂性,推而广之,实现测试和运维的标准化,敏捷支撑上面的业务应用和场景。”王璞说道。

数人云始终围绕PaaS和应用来帮助企业客户交付IT能力。将关注的重心转向微服务架构的逻辑在于,架构对于企业IT来说是最根本的,关乎到长期的IT环境的先进性和高效,保障应用的持续迭代,业务快速响应。一个有长久生命力的系统必然有一个设计高明的架构,架构必须具备灵活性,同时易用性、安全性、稳定性恒久不变。“微服务架构是云时代的IT架构,在云化转型的时代,企业客户最匹配的就是微服务云计算原生架构。”








在云生态方面,数人云先后与宇信科技、高阳金信等金融领域领先IT解决方案提供商,以及首都在线等基础IaaS厂商结成合作伙伴,共同深挖行业,为客户交付从应用到平台更完善的IT能力,推动企业云化转型。

招银云创:容器已成熟采摘正当时

招银云创是招商银行的全资子公司,致力于将招商银行IT系统30年稳定运行的成功经验和金融IT成熟解决方案开放给金融同业。招银云创战略研究院总监陈沙克受邀在此次大会上做了《容器已成熟 采摘正当时》的主题演讲,分享招银云创的容器PaaS实践。

他指出,金融行业云有突出的行业特性:强监管、强安全和高复杂度。随着Fintech驱动业务创新和互联网的普及,银行IT不仅要支撑传统核心业务,系统定制化满足大客户需求,而且要重视发展2C业务。

面对互联网化IT和客户定制化双重需求,招银云创构建的容器PaaS平台包括SpringCloud开发框架、容器运行时管理平台和容器周边管理配套工具三方面。回顾招银云创PaaS经验,陈沙克强调,目前招银云创最关注的是容器周边管理工具,这是“企业用好容器的关键”。容器让金融行业云应用变得标准化、简单化,打造了快速应变,构建开放、弹性、安全可控新型IT,满足了银行业务的创新需求。对于招银云创来说,容器和PaaS正在让“开发人员再也看不到IaaS”。

作为PaaS Innovation大会的联合主办方,中国电子技术标准化研究院软件工程与评估中心主任、中国开源云联盟秘书长周平莅临现场并致开幕辞,他分享了开源技术如何推动产业创新,以及国内开源技术现况,并与开源云联盟容器工作组成员单位共同权威发布《企业级容器云平台》联盟标准。容器标准的发布意味着容器技术迅速成熟,进入全面落地阶段,产业化进程将大大加速。

此外,大会还邀请到了国家青年千人计划学者、清华大学交叉研究院助理院长徐葳,他在《数据中心和“智能”》的主题演讲中,和与会嘉宾分享了GPU容器集群、AI等更智能数据中心的最新研究成果。

在大会最后的圆桌环节,嘉宾们就PaaS认知、传统企业如何切入PaaS、PaaS在企业数字化转型中的作用,开源技术商业化,以及如何看待云计算风口等话题展开了热烈的圆桌讨论。在全面云化的今天,PaaS作为平台层崛起风口已现,上下游合作伙伴将一起携手推进传统企业上云,为传统企业提供更多贴近业务场景的技术、应用和解决方案。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。 查看全部
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。本次大会由于汇聚了前瞻的PaaS洞察,着眼PaaS技术创新和演进趋势;梳理PaaS落地行业痛点,分享金融标杆客户最佳行业实践、重磅发布企业级容器云平台标准及推导PaaS落地方法,而广受业界瞩目。来自行业的专家、媒体朋友、生态伙伴,以及金融、能源、快消、制造等传统行业客户300余人参加了此次大会。


QQ图片20171117150208.png



企业IT变革:轻量化、敏捷化、开源化

数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。传统商业正在被技术深度改变,互联网与传统行业结合的模式探索开始在各行业展开,新金融、新零售、新制造等新的业态不断涌现。在探求数字化转型过程中,无论是技术、人员,还是体制、运营管理,都并非简单的架构调整即可为之,传统业务和互联网场景应用将长期双态并存。

在互联网+重构业务形态的驱动下,传统企业纷纷开拓互联网业务来加大自身的行业竞争优势,这给复杂的响应缓慢的传统IT架构带来严峻挑战。企业IT部门和IT管理者疲于奔命。

王璞在演讲中指出,轻量化、敏捷化和开源化是近年企业IT架构三大最重要的技术演变趋势。

2.png


首先,应用容器化、架构微服务化,使得企业级应用变得越来越轻。其次,传统企业开始践行DevOps理念,打造开发运维一体化。将整个从开发到运维的全生命周期整合为统一的流程,研发人员可以专注业务开发本身,无需关注底层技术细节。运维人员大量采用自动化运维平台和工具,运维效率显著提升。由此,敏捷开发和业务敏捷性有了实现的可能。

第三,IT基础设施软件全面拥抱开源。开源技术能够增强企业的自主可控能力,开源可拓展的IT成为企业CIO和其他IT管理者在进行技术选型和新项目建设时的重要选择方向。同时,开源技术更新迭代频繁,也对企业级IT在技术选型上提出了挑战,需要不断在各种技术之间取长补短。

PaaS技术变革:应用容器化、服务网格化、生态行业化

PaaS正在成为云计算市场中增长最快的一极。尽管在大众的印象中,云计算三层之前始终是两家独大,不过最近几年,PaaS表现出强劲的发展势头。据IDC最新的全球半年度公有云服务支出指南,2017年PaaS支出增速五年复合年增长率为32.2%。

3.png



PaaS通过技术不断创新积累,深入到企业应用领域,赢得市场,为应用交付、资源管理、运维效率、业务支撑提供了基于新一代IT架构的重要支撑体系。凭借团队在互联网应用架构和企业级IT的丰富经验,并扎根行业,做深做透客户业务特性,王璞在演讲中指出,当前PaaS呈现出应用容器化、服务网格化和行业生态化三大技术趋势。

容器经过4年的迅速发展,已经成为云计算原生应用的标准交付方式,能够对底层基础架构资源实现快速、标准化和更轻量级的管理。其次,微服务将成为云计算原生应用的标准开发架构,传统企业客户对微服务应用的管理需求日益强烈。敏捷开发和部署举步维艰,其中最大的障碍是应用太复杂,以至于单个开发者很难搞懂。微服务架构下,技术选型去中心化,团队可以自由选择合适的技术栈。同时,当需要对技术栈进行升级,面临的风险也小得多。

在以微服务和容器技术为核心的技术转型下,新一代服务网络技术方兴未艾。服务网格技术在云环境下,能够对应用进行更好地管理。开发人员在开发应用时,不必考虑后端管理上的诉求,让开发变得更透明。另外,服务网格技术对后期应用程序的管理维护能够提供更丰富的手段,以及更细粒度的管理。

行业生态化也是PaaS演进的一大重要趋势,企业级IT服务逐步向行业云过渡。数人云通过与生态伙伴合作共同落地私有云、行业云,整合行业内云产业链上IaaS、PaaS和SaaS三层资源,为企业客户提供整体解决方案。王璞强调,在行业云发展的过程中,不仅业务特性突出的SaaS具备行业属性,偏下层的IaaS和PaaS同样具备行业属性,如此更好地实现企业IT资源和服务整合。

PaaS表现出强劲的发展势头,也是行业生态化使然。随着企业应用市场的爆发和成熟,SaaS对PaaS层的要求越来越高,应用要打通、跨层、效率、协作等,这在客观上推动了PaaS体量猛增。

PaaS落地:数人云DataMan OS+EAMS

数人云是国内轻量化PaaS的首倡者,具备PaaS层面丰富的产品线,通过DataMan OS和EAMS两大产品帮助企业客户建立标准化、统一化、模块化的企业级IT体系,落地敏捷IT能力。


4.png



DataMan OS是数人云产品的底座,利用容器实现应用标准化交付和统一化运维管理,为用户IT系统带来高可用、弹性伸缩。

EAMS产品基于Spring Cloud微服务开发框架,实现针对微服务应用的统一化服务治理、业务应用模块化,落地敏捷开发,帮助传统企业落地贯穿应用全生命周期的DevOps最佳实践。

“企业要获得敏捷IT,落地DevOps能力,从开发源头上,首先必须进行开发框架的标准化。微服务开发框架解决了应用的复杂性,推而广之,实现测试和运维的标准化,敏捷支撑上面的业务应用和场景。”王璞说道。

数人云始终围绕PaaS和应用来帮助企业客户交付IT能力。将关注的重心转向微服务架构的逻辑在于,架构对于企业IT来说是最根本的,关乎到长期的IT环境的先进性和高效,保障应用的持续迭代,业务快速响应。一个有长久生命力的系统必然有一个设计高明的架构,架构必须具备灵活性,同时易用性、安全性、稳定性恒久不变。“微服务架构是云时代的IT架构,在云化转型的时代,企业客户最匹配的就是微服务云计算原生架构。”


5.png



在云生态方面,数人云先后与宇信科技、高阳金信等金融领域领先IT解决方案提供商,以及首都在线等基础IaaS厂商结成合作伙伴,共同深挖行业,为客户交付从应用到平台更完善的IT能力,推动企业云化转型。

招银云创:容器已成熟采摘正当时

招银云创是招商银行的全资子公司,致力于将招商银行IT系统30年稳定运行的成功经验和金融IT成熟解决方案开放给金融同业。招银云创战略研究院总监陈沙克受邀在此次大会上做了《容器已成熟 采摘正当时》的主题演讲,分享招银云创的容器PaaS实践。

他指出,金融行业云有突出的行业特性:强监管、强安全和高复杂度。随着Fintech驱动业务创新和互联网的普及,银行IT不仅要支撑传统核心业务,系统定制化满足大客户需求,而且要重视发展2C业务。

面对互联网化IT和客户定制化双重需求,招银云创构建的容器PaaS平台包括SpringCloud开发框架、容器运行时管理平台和容器周边管理配套工具三方面。回顾招银云创PaaS经验,陈沙克强调,目前招银云创最关注的是容器周边管理工具,这是“企业用好容器的关键”。容器让金融行业云应用变得标准化、简单化,打造了快速应变,构建开放、弹性、安全可控新型IT,满足了银行业务的创新需求。对于招银云创来说,容器和PaaS正在让“开发人员再也看不到IaaS”。

作为PaaS Innovation大会的联合主办方,中国电子技术标准化研究院软件工程与评估中心主任、中国开源云联盟秘书长周平莅临现场并致开幕辞,他分享了开源技术如何推动产业创新,以及国内开源技术现况,并与开源云联盟容器工作组成员单位共同权威发布《企业级容器云平台》联盟标准。容器标准的发布意味着容器技术迅速成熟,进入全面落地阶段,产业化进程将大大加速。

此外,大会还邀请到了国家青年千人计划学者、清华大学交叉研究院助理院长徐葳,他在《数据中心和“智能”》的主题演讲中,和与会嘉宾分享了GPU容器集群、AI等更智能数据中心的最新研究成果。

在大会最后的圆桌环节,嘉宾们就PaaS认知、传统企业如何切入PaaS、PaaS在企业数字化转型中的作用,开源技术商业化,以及如何看待云计算风口等话题展开了热烈的圆桌讨论。在全面云化的今天,PaaS作为平台层崛起风口已现,上下游合作伙伴将一起携手推进传统企业上云,为传统企业提供更多贴近业务场景的技术、应用和解决方案。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。

浅论Prometheus容器监控优缺点,2.0版本哪项改进受关注?

杨y 发表了文章 • 1 个评论 • 144 次浏览 • 2017-11-14 22:12 • 来自相关话题

 
关于容器监控,数人云之前给大家分享了《解惑|你是否为容器监控操碎了心?》,就有有Prometheus的身影,那么它都有哪些优缺点?近日发布的2.0版本又有哪些改进?本文见分晓~

Prometheus解决了Devs如何监控高动态容器环境的问题,在本文中,Frederick Ryckbosch讲述了使用Prometheus的优点和缺点,以及它到底有多大的伸缩性。

Prometheus是一个基于时间序列的数值数据的监控解决方案,这是一个开源项目,由前Google员工在SoundCloud启动,他们希望监控一个高度动态的容器环境,因为对传统的监控工具不甚满意,所以开发出Prometheus,并在上面进行工作。

在本文中,我们将讨论Prometheus的重要设计决策及其影响,将重点讨论“ Digital Ocean”如何成功地将Prometheus扩展到100万台机器,以及在使用Coscale时如何利用Prometheus。

Prometheus是如何工作的

要使用Prometheus监控服务,服务需要公开一个Prometheus端点,这端点是一个HTTP借口,它公开了度量的列表和当前的值。

Prometheus提供了广泛的服务发现选项,以查找您的服务并从它们开始检索度量数据。Prometheus服务器轮询服务的指标接口并存储数据。

在Prometheus UI中,用户可以在PromQL语言中编写查询以提取度量信息。

例如:topk(3, sum(rate(container_cpu_time[5m]) by (app, proc)))将返回最上面的3个CPU消费服务。

告警可以在Alertmanager中配置,再次使用PromQL语言。Grafana 是一个流行的选项,为Prometheus的指标创建仪表盘。








Prometheus的设计决策

这里从Prometheus的度量终点开始,这些端点定义度量标准和值,并通过HTTP公开,它们为手机度量标准提供了一种标准化的方法,Prometheus度量遵循了度量2.0所指定的许多准则:度量标准有名称、描述、维度和值。唯一缺少的是度量单位。

许多服务度暴露了Prometheus端点,这使得收集它们非常容易,对没有本地Prometheus端点的其他服务,则需要转换器。这意味着对于这些服务,必须部署一个额外的Sidecar容器,以公开Prometheus格式的字表。

在这里讨论的第二个设计决定是拉力和推力,Prometheus调查服务的指标,这意味着如果您想要使用Prometheus监控的所有服务都应该公开Prometheus度量端点,Prometheus使用服务发现,它与Kubernetes很好的集成在一起,以找到所有的服务一旦它找到了所有服务,将通过轮询其他Prometheus度量端点收集所有这些服务的指标。

容器

Pull方法的优点是不需要安装代理,而且可以通过多个Prometheus实例来提取指标。

而缺点同样明显:

对于Prometheus的使用者来说,所有的公制端点都必须是可达的,这意味着一个更加复杂的安全网络配置。

在大型部署中,扩展成为一个问题,Prometheus建议采用一种基于推特的方法来收集短期的工作指标。

Prometheus的主要设计目标之一是操作简单性。这样,Prometheus就限制了监控系统的可能失效模式数量,遵循着一原则,Prometheus目前只局限于单个点,因为集群带来了额外的操作复杂性,使用单个节点不那么复杂,但是对可以由Prometheus监控的度量指标适量有着严格的限制。

Prometheus不解决的问题

Prometheus并不打算解决几个方面的问题:

首先是对日志的支持:这两个指标和日志都是为用户的应用程序提供完全可见性的必要部分,但是已经有大量的开源和闭源日志聚合器来管理日志。

Prometheus也不提供持久的长期存储、异常检测、自动水平缩放和用户管理,但从作者的客户基础上,看到在多数企业环境中都需要这些特性。

Prometheus不是一个Dashboarding解决方案,它提供了一个简单的UI来进行PromQL查询,但它依赖于移植物的操作,增加了一些额外的设置复杂度。

Prometheus与Digital Ocean

在2016年的PromCon演讲中,来自Digital Ocean的Matthew Campbell解释了它们如何将Prometheus扩展到100万台的,在演讲当中,他解释了他们是怎样从一个默认的Prometheus装置开始的,以及他们必须改变什么,才能让它变得更大。

他们以每天数据中心的一台Prometheus机开始,遇到了可伸缩性问题,并创建了更大的机器来运行Prometheus。一旦他们将机器按最大尺寸缩放,他们将系统保留时间减少到3天,并决定放弃某些指标。这种方法只能到目前为止,因此他们决定根据节点标签进一步提高他们的Prometheus,这种方法的困难在于,查询变得更加困难,他们最终实现了一个从多个碎片收集数据的Prometheus代理,他们无法用这种方法解决更大的问题是碎片重新分配和过度供应。

当从1万个服务器扩展到100万个虚拟机时,他们决定采取不同的方法,创建了一个“反向节点出口商”,它基本上是安装在节点上的代理,并将数据推到一个中心点,在后端方面,他们也做了重大的改变:保留了Prometheus API,但添加了一个Kafka集群,用于传入的指标和Cassandra的度量存储,他们还介绍了采样,这个项目被称为Vulcan,可用作开源。

Vulcan所采取的方法看起来很像CoScale所采取的方法,还使用代理和可伸缩、高可用的后端。

CoScal在哪里合适?

我们相信有一个标准化的度量格式有很大的价值,这使得从不同类型的服务中心收集指标变得很容易,CoScale提供了一个Prometheus插件,它收集了在Prometheus格式中暴露的指标,这使得您可以轻松地从已启动的服务中获得指标。

但是仍然有很多服务没有暴露出Prometheus端点。为这些服务部署一个转换器非常麻烦,CoScale有广泛的插件,支持多种服务的本地度量机制;录用日志、Api和其他线程的度量计数器。我们还提供了收集自定义指标的不同选项。

CoScale提供了一个可扩展的插件,包括一个代理和和一个可扩展的、高可用的后端作为SaaS和On-Premise,CoScale提供了Metrics,指标,和事件存储(短期和长期),直观的仪表盘,告警和异常检测。

Prometheus 2.0

Prometheus 1.0于2016年7月发布,就在前几天,Prometheus发布了2.0的版本,带来了巨大的性能改进,并变得更容易操作,下面让我们看看这个版本都有哪些方面的改进。

许多公司和组织都采用了Prometheus,这个项目很快就拥有了一大批的活跃粉丝(开发人员)以及技术社区。5月的时候就传出Prometheus 2.0版本的前瞻预测,据说会有一个很大的改进是,有新的存储层,这意味着极大地提高了Kubernetes和其他分布式系统的监控可伸缩性。

Prometheus有一个简单而健壮的操作模式,然而,基础设施领域也在逐步发展,如Kubernetes何Mesos这样的项目迅速地改变了应用部署和管理的方式,受监控的环境变得越来越动态化。

Prometheus存储子系统需要仔细配置预期负载,虽然在Prometheus 1.6中,自动调谐能力让其大为减轻,但用户仍然会遇到一些不可避免的硬限制。

存储

2017年,事情逐步发生改变,最初作为一种新的,更高效的时间序列数据库的实验,在实际的基准测试中得到了验证,在过去的6个月当中,Prometheus的开发团队一直在忙着稳定这个独立的时间序列数据库,并将其重新整合到Prometheus本身,其结果上,几乎所有的维度上都有了改进,从而显著地提高了Prometheus 2.0的性能,查询延迟更为一致,特别是在高串扰的情况下,在不同的实际生产场景中,度量的资源消耗也显著减少:

与Prometheus 1.8相比,CPU使用率降低了20%-40%
与Prometheus 1.8相比,磁盘空间使用减少到33%-50%
没有太多查询负载的磁盘I/O通常小于1%








在未来的几年里,它还可以处理现代计算环境日益增长的动态特性。

Staleness handling

此外,许多以小见大的变化使得Prometheus更加直观,最值得注意的是Staleness处理,它是最古老和最需要路线图的项目之一,随着新的改进,从这些目标中消失的监控目标或系列已经被明确跟踪,这减少了人工查询,增强了告警响应能力。

其他改进

Prometheus 2.0还内置了对整个数据库快照备份的支持。

同时,还将记录和告警规则从一个自定义格式迁移到无处不在的YAML格式,这使得集成配置管理和模块变得更加容易。

其他的变动改进请参看:https://prometheus.io/docs/pro ... tion/

未来计划

会将新的存储子系统设计为可访问和可扩展的,这就需要将新特性直接集成到Prometheus中,以及可以在它之上构建的定制工具,简单而开放的存储格式和库也允许用户轻松构建自定义扩展,比如动态保留策略,这使得存储层能够满足广泛的需求,而无需将复杂性引入到Prometheus本身中,让它专注于它的核心目标。 查看全部

1.png

 
关于容器监控,数人云之前给大家分享了《解惑|你是否为容器监控操碎了心?》,就有有Prometheus的身影,那么它都有哪些优缺点?近日发布的2.0版本又有哪些改进?本文见分晓~

Prometheus解决了Devs如何监控高动态容器环境的问题,在本文中,Frederick Ryckbosch讲述了使用Prometheus的优点和缺点,以及它到底有多大的伸缩性。

Prometheus是一个基于时间序列的数值数据的监控解决方案,这是一个开源项目,由前Google员工在SoundCloud启动,他们希望监控一个高度动态的容器环境,因为对传统的监控工具不甚满意,所以开发出Prometheus,并在上面进行工作。

在本文中,我们将讨论Prometheus的重要设计决策及其影响,将重点讨论“ Digital Ocean”如何成功地将Prometheus扩展到100万台机器,以及在使用Coscale时如何利用Prometheus。

Prometheus是如何工作的

要使用Prometheus监控服务,服务需要公开一个Prometheus端点,这端点是一个HTTP借口,它公开了度量的列表和当前的值。

Prometheus提供了广泛的服务发现选项,以查找您的服务并从它们开始检索度量数据。Prometheus服务器轮询服务的指标接口并存储数据。

在Prometheus UI中,用户可以在PromQL语言中编写查询以提取度量信息。

例如:topk(3, sum(rate(container_cpu_time[5m]) by (app, proc)))将返回最上面的3个CPU消费服务。

告警可以在Alertmanager中配置,再次使用PromQL语言。Grafana 是一个流行的选项,为Prometheus的指标创建仪表盘。


2.png



Prometheus的设计决策

这里从Prometheus的度量终点开始,这些端点定义度量标准和值,并通过HTTP公开,它们为手机度量标准提供了一种标准化的方法,Prometheus度量遵循了度量2.0所指定的许多准则:度量标准有名称、描述、维度和值。唯一缺少的是度量单位。

许多服务度暴露了Prometheus端点,这使得收集它们非常容易,对没有本地Prometheus端点的其他服务,则需要转换器。这意味着对于这些服务,必须部署一个额外的Sidecar容器,以公开Prometheus格式的字表。

在这里讨论的第二个设计决定是拉力和推力,Prometheus调查服务的指标,这意味着如果您想要使用Prometheus监控的所有服务都应该公开Prometheus度量端点,Prometheus使用服务发现,它与Kubernetes很好的集成在一起,以找到所有的服务一旦它找到了所有服务,将通过轮询其他Prometheus度量端点收集所有这些服务的指标。

容器

Pull方法的优点是不需要安装代理,而且可以通过多个Prometheus实例来提取指标。

而缺点同样明显:

对于Prometheus的使用者来说,所有的公制端点都必须是可达的,这意味着一个更加复杂的安全网络配置。

在大型部署中,扩展成为一个问题,Prometheus建议采用一种基于推特的方法来收集短期的工作指标。

Prometheus的主要设计目标之一是操作简单性。这样,Prometheus就限制了监控系统的可能失效模式数量,遵循着一原则,Prometheus目前只局限于单个点,因为集群带来了额外的操作复杂性,使用单个节点不那么复杂,但是对可以由Prometheus监控的度量指标适量有着严格的限制。

Prometheus不解决的问题

Prometheus并不打算解决几个方面的问题:

首先是对日志的支持:这两个指标和日志都是为用户的应用程序提供完全可见性的必要部分,但是已经有大量的开源和闭源日志聚合器来管理日志。

Prometheus也不提供持久的长期存储、异常检测、自动水平缩放和用户管理,但从作者的客户基础上,看到在多数企业环境中都需要这些特性。

Prometheus不是一个Dashboarding解决方案,它提供了一个简单的UI来进行PromQL查询,但它依赖于移植物的操作,增加了一些额外的设置复杂度。

Prometheus与Digital Ocean

在2016年的PromCon演讲中,来自Digital Ocean的Matthew Campbell解释了它们如何将Prometheus扩展到100万台的,在演讲当中,他解释了他们是怎样从一个默认的Prometheus装置开始的,以及他们必须改变什么,才能让它变得更大。

他们以每天数据中心的一台Prometheus机开始,遇到了可伸缩性问题,并创建了更大的机器来运行Prometheus。一旦他们将机器按最大尺寸缩放,他们将系统保留时间减少到3天,并决定放弃某些指标。这种方法只能到目前为止,因此他们决定根据节点标签进一步提高他们的Prometheus,这种方法的困难在于,查询变得更加困难,他们最终实现了一个从多个碎片收集数据的Prometheus代理,他们无法用这种方法解决更大的问题是碎片重新分配和过度供应。

当从1万个服务器扩展到100万个虚拟机时,他们决定采取不同的方法,创建了一个“反向节点出口商”,它基本上是安装在节点上的代理,并将数据推到一个中心点,在后端方面,他们也做了重大的改变:保留了Prometheus API,但添加了一个Kafka集群,用于传入的指标和Cassandra的度量存储,他们还介绍了采样,这个项目被称为Vulcan,可用作开源。

Vulcan所采取的方法看起来很像CoScale所采取的方法,还使用代理和可伸缩、高可用的后端。

CoScal在哪里合适?

我们相信有一个标准化的度量格式有很大的价值,这使得从不同类型的服务中心收集指标变得很容易,CoScale提供了一个Prometheus插件,它收集了在Prometheus格式中暴露的指标,这使得您可以轻松地从已启动的服务中获得指标。

但是仍然有很多服务没有暴露出Prometheus端点。为这些服务部署一个转换器非常麻烦,CoScale有广泛的插件,支持多种服务的本地度量机制;录用日志、Api和其他线程的度量计数器。我们还提供了收集自定义指标的不同选项。

CoScale提供了一个可扩展的插件,包括一个代理和和一个可扩展的、高可用的后端作为SaaS和On-Premise,CoScale提供了Metrics,指标,和事件存储(短期和长期),直观的仪表盘,告警和异常检测。

Prometheus 2.0

Prometheus 1.0于2016年7月发布,就在前几天,Prometheus发布了2.0的版本,带来了巨大的性能改进,并变得更容易操作,下面让我们看看这个版本都有哪些方面的改进。

许多公司和组织都采用了Prometheus,这个项目很快就拥有了一大批的活跃粉丝(开发人员)以及技术社区。5月的时候就传出Prometheus 2.0版本的前瞻预测,据说会有一个很大的改进是,有新的存储层,这意味着极大地提高了Kubernetes和其他分布式系统的监控可伸缩性。

Prometheus有一个简单而健壮的操作模式,然而,基础设施领域也在逐步发展,如Kubernetes何Mesos这样的项目迅速地改变了应用部署和管理的方式,受监控的环境变得越来越动态化。

Prometheus存储子系统需要仔细配置预期负载,虽然在Prometheus 1.6中,自动调谐能力让其大为减轻,但用户仍然会遇到一些不可避免的硬限制。

存储

2017年,事情逐步发生改变,最初作为一种新的,更高效的时间序列数据库的实验,在实际的基准测试中得到了验证,在过去的6个月当中,Prometheus的开发团队一直在忙着稳定这个独立的时间序列数据库,并将其重新整合到Prometheus本身,其结果上,几乎所有的维度上都有了改进,从而显著地提高了Prometheus 2.0的性能,查询延迟更为一致,特别是在高串扰的情况下,在不同的实际生产场景中,度量的资源消耗也显著减少:

与Prometheus 1.8相比,CPU使用率降低了20%-40%
与Prometheus 1.8相比,磁盘空间使用减少到33%-50%
没有太多查询负载的磁盘I/O通常小于1%


3.png



在未来的几年里,它还可以处理现代计算环境日益增长的动态特性。

Staleness handling

此外,许多以小见大的变化使得Prometheus更加直观,最值得注意的是Staleness处理,它是最古老和最需要路线图的项目之一,随着新的改进,从这些目标中消失的监控目标或系列已经被明确跟踪,这减少了人工查询,增强了告警响应能力。

其他改进

Prometheus 2.0还内置了对整个数据库快照备份的支持。

同时,还将记录和告警规则从一个自定义格式迁移到无处不在的YAML格式,这使得集成配置管理和模块变得更加容易。

其他的变动改进请参看:https://prometheus.io/docs/pro ... tion/

未来计划

会将新的存储子系统设计为可访问和可扩展的,这就需要将新特性直接集成到Prometheus中,以及可以在它之上构建的定制工具,简单而开放的存储格式和库也允许用户轻松构建自定义扩展,比如动态保留策略,这使得存储层能够满足广泛的需求,而无需将复杂性引入到Prometheus本身中,让它专注于它的核心目标。

SRE|当Google的核心准则遇到Xero的最佳实践

杨y 发表了文章 • 0 个评论 • 133 次浏览 • 2017-11-14 15:55 • 来自相关话题

关于SRE,数人云之前给大家分享很多相关的文章,想必大家已经有了一定的了解,今天给大家带来的这篇文章,分别从Xero和Google的角度讨论一些工具和框架,以及SRE的一些准则。

Xero的SRE之路

作为一个SRE,作者主要关心的是如何保持应用平台的稳定,减少崩溃,然而这也是不能避免的,本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的,因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题,都是通过监控基础设施进行检测的,用于告警的通道工具已经随着时间的推移而发生了变化,但是基本的流程仍然大同小异,如下图所示:






自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作,理想的情况下, 所有的告警都应该是自动化的,但有时我们会接触到一些没有被发现的问题,所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline,因此决定将这些请求转换为自动告警,如下所示:






 
手动报警Pipeline

使用这种方法,自动和手动告警都以同样的方式送达工程师,但是每个告警都有什么呢?

剖析一个告警

出现了什么错误?问题的性质和严重性?
故障出现后,都有哪些地方收到了影响?
它怎么能固定下来呢?链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求,对于手工报告的问题,依赖于通过在线表单提供这些信息,希望填写表格的过程是速度且无痛的,所以只有第一个问题是强制性的:

能否概括一下这个问题,比如,到底出了什么问题?
哪个站点/URL有问题?可以帮助识别受影响的地方。
问题是否仅限于特定的地点,帮助我们隔离网络/CDN问题。
问题是什么时候开始的?帮助设置日志/度量搜索的时间尺度。
谁在关注这些问题?这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确,但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统,允许我们建立多个On-call团队,定义每个团队的轮换,并将每个团队连接到监控基础设施,告警是针对拥有受影响系统的团队的,但是SRE为每个团队提供了额外的层,如下所示:








告警升级

在20多个产品和服务的呼叫团队中,On-call管理配置已经演化为相当复杂的设置,随着越来越多的团队加入其中,我们的支持模式也在不断地发展,要手动设置所有的东西将是一项艰巨的任务,处于这个原因,我们创建了一个“On-call as code”系统,类似于Chef这样的基础设施代码框架。








On-call configuration pipeline

延伸阅读:

Chef 是一款自动化服务器配置管理工具,可以对所管理的对象实行自动化配置,如系统管理,安装软件等。Chef 由三大组件组成:Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器,维护了一套配置脚本(Cookbook),与每个被管节点(Chef Node)交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口:我们在 Workstation 上创建定义 Cookbook,并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点,可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令(Cookbook)并按照指令配置自己。 一套 Chef 环境包含一个 Chef Server,至少一个 Chef Workstation,以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置,然后,CI/CD系统运行一个Rake任务,它通过调用管理系统来同步存储库,这种方法为我们提供了一系列的好处:

所有的配置更改都可以通过标准的Git工作流进行同行评审。

CI服务器可以“Lint”每个配置更改,以验证它满足一些基本需求(例如,每个团队需要一个管理员)。

允许团队手动设置他们的调用轮换,因为On-call系统的Web界面提供了一种简单的方法,然而,团队调用设置的所有其他组件都由同步任务执行。

新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来,同步任务从一个最小的配置文件自动地构建每个团队的调用配置,如果团队需要一个不寻常的调用设置,那他们就可以置顶额外的配置文件来这样做。

未来,可以很容易地改变所有团队的标准调用配置,例如更改每次升级之间的时间限制。

在这些倡议中,我们为管理良好的时间奠定了基础:

告警以相同的方式发出,无论它们是自动检测还是手动报告。

每个告警的内容都包含了足够的信息,让工程师开始计划响应。

On-Call作为代码系统,确保所有的团队都能以一致的方式接受告警。

虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别,但都与他们支持的服务有着基本的信任,并坚持相同的核心原则。

一般来说,SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互(不仅仅是生产环境,还包括开发团队、测试团队、用户等等)制定了相关的规则和原则,这些规则和工作实践帮助我们保持对工程工作的关注,而不是运维工作。

Google SRE准则
确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限,他们的剩余时间应该用在项目工作的编程技能上,在实践当中,这是通过监控SRE们所做的运维工作数量来完成的,并将多余的运维工作重新定向到产品开发团队:重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时,重新向结束,这也提供了一个有效的反馈机制,引导开发人员构建不需要人工干预的系统,当整个组织——SRE和开发人员理解为什么这个机制存在时,这种方法很有效,并且支持没有溢出事件的目标,因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时,在平均每8-12小时中,SRE应该最多接受两个事件,这个目标量给呼叫工程师足够的时间准确快速地处理事件,清理和恢复正常服务,然后进行事后剖析,如果有两个以上的事件经常发生在呼叫转移上,问题就无法彻底调查,工程师们也无法从这些事件中吸取教训,一种寻呼机疲劳的情况下也不会随着规模而提高,相反,如果每次转换时,调用的SRE始终接受不到一个事件,那么这就无异于在浪费时间。

对于所有重大事件,无论是否寻呼,都应该写死后的纪录,没有触发界面的后期纪录甚至更有价值,因为它们可能指出了明显的监控漏洞,这个调查应该确定发生的细节,找出事件的所有根源,并分配行动来纠正问题化或改进下次处理的方法,Google在一个免费的分析文化下运行,目标是揭露出错误并应用工程来修复这些错误,而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系,结构冲突是在创新和产品稳定性之间,正如前面所述,这种冲突往往是间接表达的,在SRE中,我们将这个冲突引入到前面,然后通过引入错误预算来解决它。

预算错误源于这样一种观察, 即100%是所有东的错误可靠性目标,一般来说,对于任何软件服务或系统100%可用和99.999%可用,有许多其他系统用户和服务之间的路径(他们的笔记本电脑,家里的WIFI,ISP,电网……),这些系统集体远远低于99.999%,因此,99.999……和100%的差异在于其他不可用性的丢失,而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标,那么,系统的正确可靠性目标是什么?这实际上并不是一个技术问题——这是一个产品问题,应该考虑以下因素:

考虑到他们是如何使用产品的,用户满意的程度是多少?

对于那些对产品的可用性不满意的用户有什么选择?

用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标,一旦确定了目标,错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用,允许0.01的不可用性是服务的错误预算,我们可以把预算画在问么想要的任何东西上,只要不超支。

那么要如何花费这个错误预算呢?开发团队希望推出特性并吸引新用户,理想情况下,我们会把所有的错误预算都花在我们发布的新产品上,以快速启动它们,这个基本前提描述了整个错误预算模型,一旦SRE活动在这个框架中被概念化,通过注入阶段性的滚转和1%的实验等策略释放错误预算,可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突,SRE的目标实在是“0消耗”;相反,SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上,这种改变造成了不同,宕机不再是“坏”的事情——它是创新过程中预期的一部分,而且发展和SRE团队都在管理,而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一,因此,应当深思熟虑地构建监控策略,一个典型的、常见的监控方法是观察特定的值或条件,然后在超过该值或条件时触发电子邮件告警,然而,这种类型的电子邮件告警并不是一个有效的解决方案;一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的,监控不应该要求人对告警区域的任何部分进行解释,相反,应用应做口译,只有当它们需要采取行动时,才去通知SRE。

三种有效地监控输出:

告警:意味着SRE需要立即采取行动来应对正在发生或即将发生的事情,以改善这种情况。

Tickets:表示SRE需要采取行动,但不是马上,系统不能自动处理这种情况,但如果一个人在几天内采取了动作,就不会造成事故。

日志记录:无需日日查看的信息,但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间(MTTF)和平均修复时间(MTTR)的函数,评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态,即MTTR。 一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性,当SRE有需求时,我们发现,在“剧本”中提前记录是最佳实践,在MTTR中产生大约3倍的改进,而不是“即兴发挥”的策略,谷歌SRE依赖于on -call playbooks,除了诸如“不幸之轮”这样的练习,还可以让工程师对on - call事件做出反应。

效率和性能

任何时候,有效利用资源都是非常重要的,由于SRE最终控制了供应,因此它也必须参与任何有关使用的工作,因为利用率是给定服务如何工作的一个函数,以及它是如何响应的。密切关注服务的供应策略,它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求(负载)、容量和应用效率的函数。SRE预测需求,提供能力,并可以修改软件,这三个因素是服务效率的很大一部分(尽管不是全部)。

随着负载的增加,应用系统会变得越来越慢,服务的减少等同于能力的丧失,在某一个时刻,当某个缓慢的系统停止服务,这相当于无限的慢。SRE提供以特性的响应速度满足容量目标,因此对服务的性能非常感兴趣,SRE和产品开发人员将(并且应该)监控和修改服务以提高其性能,从而增加容量和提高效率。

以上是小数今天给大家分享的文章,众所周知,SRE的理念最早出自Google,而数人云老王(王璞)曾供职于Google的广告部门,对于SRE有着深入的研究,在数人云的Meetup上就曾以SRE为题进行了多次分享,同时小数也给大家分享了多篇SRE相关的文章,有兴趣的可以点击查看: 查看全部

1.png



关于SRE,数人云之前给大家分享很多相关的文章,想必大家已经有了一定的了解,今天给大家带来的这篇文章,分别从Xero和Google的角度讨论一些工具和框架,以及SRE的一些准则。

Xero的SRE之路

作为一个SRE,作者主要关心的是如何保持应用平台的稳定,减少崩溃,然而这也是不能避免的,本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的,因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题,都是通过监控基础设施进行检测的,用于告警的通道工具已经随着时间的推移而发生了变化,但是基本的流程仍然大同小异,如下图所示:


2.png

自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作,理想的情况下, 所有的告警都应该是自动化的,但有时我们会接触到一些没有被发现的问题,所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline,因此决定将这些请求转换为自动告警,如下所示:


3.png

 
手动报警Pipeline

使用这种方法,自动和手动告警都以同样的方式送达工程师,但是每个告警都有什么呢?

剖析一个告警

出现了什么错误?问题的性质和严重性?
故障出现后,都有哪些地方收到了影响?
它怎么能固定下来呢?链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求,对于手工报告的问题,依赖于通过在线表单提供这些信息,希望填写表格的过程是速度且无痛的,所以只有第一个问题是强制性的:

能否概括一下这个问题,比如,到底出了什么问题?
哪个站点/URL有问题?可以帮助识别受影响的地方。
问题是否仅限于特定的地点,帮助我们隔离网络/CDN问题。
问题是什么时候开始的?帮助设置日志/度量搜索的时间尺度。
谁在关注这些问题?这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确,但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统,允许我们建立多个On-call团队,定义每个团队的轮换,并将每个团队连接到监控基础设施,告警是针对拥有受影响系统的团队的,但是SRE为每个团队提供了额外的层,如下所示:


4.png



告警升级

在20多个产品和服务的呼叫团队中,On-call管理配置已经演化为相当复杂的设置,随着越来越多的团队加入其中,我们的支持模式也在不断地发展,要手动设置所有的东西将是一项艰巨的任务,处于这个原因,我们创建了一个“On-call as code”系统,类似于Chef这样的基础设施代码框架。


5.png



On-call configuration pipeline

延伸阅读:

Chef 是一款自动化服务器配置管理工具,可以对所管理的对象实行自动化配置,如系统管理,安装软件等。Chef 由三大组件组成:Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器,维护了一套配置脚本(Cookbook),与每个被管节点(Chef Node)交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口:我们在 Workstation 上创建定义 Cookbook,并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点,可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令(Cookbook)并按照指令配置自己。 一套 Chef 环境包含一个 Chef Server,至少一个 Chef Workstation,以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置,然后,CI/CD系统运行一个Rake任务,它通过调用管理系统来同步存储库,这种方法为我们提供了一系列的好处:

所有的配置更改都可以通过标准的Git工作流进行同行评审。

CI服务器可以“Lint”每个配置更改,以验证它满足一些基本需求(例如,每个团队需要一个管理员)。

允许团队手动设置他们的调用轮换,因为On-call系统的Web界面提供了一种简单的方法,然而,团队调用设置的所有其他组件都由同步任务执行。

新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来,同步任务从一个最小的配置文件自动地构建每个团队的调用配置,如果团队需要一个不寻常的调用设置,那他们就可以置顶额外的配置文件来这样做。

未来,可以很容易地改变所有团队的标准调用配置,例如更改每次升级之间的时间限制。

在这些倡议中,我们为管理良好的时间奠定了基础:

告警以相同的方式发出,无论它们是自动检测还是手动报告。

每个告警的内容都包含了足够的信息,让工程师开始计划响应。

On-Call作为代码系统,确保所有的团队都能以一致的方式接受告警。

虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别,但都与他们支持的服务有着基本的信任,并坚持相同的核心原则。

一般来说,SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互(不仅仅是生产环境,还包括开发团队、测试团队、用户等等)制定了相关的规则和原则,这些规则和工作实践帮助我们保持对工程工作的关注,而不是运维工作。

Google SRE准则
确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限,他们的剩余时间应该用在项目工作的编程技能上,在实践当中,这是通过监控SRE们所做的运维工作数量来完成的,并将多余的运维工作重新定向到产品开发团队:重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时,重新向结束,这也提供了一个有效的反馈机制,引导开发人员构建不需要人工干预的系统,当整个组织——SRE和开发人员理解为什么这个机制存在时,这种方法很有效,并且支持没有溢出事件的目标,因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时,在平均每8-12小时中,SRE应该最多接受两个事件,这个目标量给呼叫工程师足够的时间准确快速地处理事件,清理和恢复正常服务,然后进行事后剖析,如果有两个以上的事件经常发生在呼叫转移上,问题就无法彻底调查,工程师们也无法从这些事件中吸取教训,一种寻呼机疲劳的情况下也不会随着规模而提高,相反,如果每次转换时,调用的SRE始终接受不到一个事件,那么这就无异于在浪费时间。

对于所有重大事件,无论是否寻呼,都应该写死后的纪录,没有触发界面的后期纪录甚至更有价值,因为它们可能指出了明显的监控漏洞,这个调查应该确定发生的细节,找出事件的所有根源,并分配行动来纠正问题化或改进下次处理的方法,Google在一个免费的分析文化下运行,目标是揭露出错误并应用工程来修复这些错误,而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系,结构冲突是在创新和产品稳定性之间,正如前面所述,这种冲突往往是间接表达的,在SRE中,我们将这个冲突引入到前面,然后通过引入错误预算来解决它。

预算错误源于这样一种观察, 即100%是所有东的错误可靠性目标,一般来说,对于任何软件服务或系统100%可用和99.999%可用,有许多其他系统用户和服务之间的路径(他们的笔记本电脑,家里的WIFI,ISP,电网……),这些系统集体远远低于99.999%,因此,99.999……和100%的差异在于其他不可用性的丢失,而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标,那么,系统的正确可靠性目标是什么?这实际上并不是一个技术问题——这是一个产品问题,应该考虑以下因素:

考虑到他们是如何使用产品的,用户满意的程度是多少?

对于那些对产品的可用性不满意的用户有什么选择?

用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标,一旦确定了目标,错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用,允许0.01的不可用性是服务的错误预算,我们可以把预算画在问么想要的任何东西上,只要不超支。

那么要如何花费这个错误预算呢?开发团队希望推出特性并吸引新用户,理想情况下,我们会把所有的错误预算都花在我们发布的新产品上,以快速启动它们,这个基本前提描述了整个错误预算模型,一旦SRE活动在这个框架中被概念化,通过注入阶段性的滚转和1%的实验等策略释放错误预算,可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突,SRE的目标实在是“0消耗”;相反,SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上,这种改变造成了不同,宕机不再是“坏”的事情——它是创新过程中预期的一部分,而且发展和SRE团队都在管理,而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一,因此,应当深思熟虑地构建监控策略,一个典型的、常见的监控方法是观察特定的值或条件,然后在超过该值或条件时触发电子邮件告警,然而,这种类型的电子邮件告警并不是一个有效的解决方案;一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的,监控不应该要求人对告警区域的任何部分进行解释,相反,应用应做口译,只有当它们需要采取行动时,才去通知SRE。

三种有效地监控输出:

告警:意味着SRE需要立即采取行动来应对正在发生或即将发生的事情,以改善这种情况。

Tickets:表示SRE需要采取行动,但不是马上,系统不能自动处理这种情况,但如果一个人在几天内采取了动作,就不会造成事故。

日志记录:无需日日查看的信息,但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间(MTTF)和平均修复时间(MTTR)的函数,评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态,即MTTR。 一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性,当SRE有需求时,我们发现,在“剧本”中提前记录是最佳实践,在MTTR中产生大约3倍的改进,而不是“即兴发挥”的策略,谷歌SRE依赖于on -call playbooks,除了诸如“不幸之轮”这样的练习,还可以让工程师对on - call事件做出反应。

效率和性能

任何时候,有效利用资源都是非常重要的,由于SRE最终控制了供应,因此它也必须参与任何有关使用的工作,因为利用率是给定服务如何工作的一个函数,以及它是如何响应的。密切关注服务的供应策略,它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求(负载)、容量和应用效率的函数。SRE预测需求,提供能力,并可以修改软件,这三个因素是服务效率的很大一部分(尽管不是全部)。

随着负载的增加,应用系统会变得越来越慢,服务的减少等同于能力的丧失,在某一个时刻,当某个缓慢的系统停止服务,这相当于无限的慢。SRE提供以特性的响应速度满足容量目标,因此对服务的性能非常感兴趣,SRE和产品开发人员将(并且应该)监控和修改服务以提高其性能,从而增加容量和提高效率。

以上是小数今天给大家分享的文章,众所周知,SRE的理念最早出自Google,而数人云老王(王璞)曾供职于Google的广告部门,对于SRE有着深入的研究,在数人云的Meetup上就曾以SRE为题进行了多次分享,同时小数也给大家分享了多篇SRE相关的文章,有兴趣的可以点击查看: