编译错误集

回复

运维技术OS小编 发起了问题 • 1 人关注 • 0 个回复 • 36 次浏览 • 6 天前 • 来自相关话题

golang静态编译

编程语言Ansible 发表了文章 • 0 个评论 • 94 次浏览 • 2020-04-30 09:43 • 来自相关话题

golang 的编译(不涉及 cgo 编译的前提下)默认使用了静态编译,不依赖任何动态链接库。

这样可以任意部署到各种运行环境,不用担心依赖库的版本问题。只是体积大一点而已,存储时占用了一点磁盘,运行时,多占用了一点内存。早期动态链接库的产生,是因为早期的系统的内存资源十分宝贵,由于内存紧张的问题在早期的系统中显得更加突出,因此人们首先想到的是要解决内存使用效率不高这一问题,于是便提出了动态装入的思想。也就产生了动态链接库。在现在的计算机里,操作系统的硬盘内存更大了,尤其是服务器,32G、64G 的内存都是最基本的。可以不用为了节省几百 KB 或者1M,几 M 的内存而大大费周折了。而 golang 就采用这种做法,可以避免各种 so 动态链接库依赖的问题,这点是非常值得称赞的。
 
显示指定静态编译方法
在Docker化的今天, 我们经常需要静态编译一个Go程序,以便方便放在Docker容器中。 即使你没有引用其它的第三方包,只是在程序中使用了标准库net,你也会发现你编译后的程序依赖glic,这时候你需要glibc-static库,并且静态连接。

不同的Go版本下静态编译方式还有点不同,在go 1.10下, 下面的方式会尽可能做到静态编译:
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' .
原文: http://suo.im/6d3eun   查看全部
golang 的编译(不涉及 cgo 编译的前提下)默认使用了静态编译,不依赖任何动态链接库。

这样可以任意部署到各种运行环境,不用担心依赖库的版本问题。只是体积大一点而已,存储时占用了一点磁盘,运行时,多占用了一点内存。早期动态链接库的产生,是因为早期的系统的内存资源十分宝贵,由于内存紧张的问题在早期的系统中显得更加突出,因此人们首先想到的是要解决内存使用效率不高这一问题,于是便提出了动态装入的思想。也就产生了动态链接库。在现在的计算机里,操作系统的硬盘内存更大了,尤其是服务器,32G、64G 的内存都是最基本的。可以不用为了节省几百 KB 或者1M,几 M 的内存而大大费周折了。而 golang 就采用这种做法,可以避免各种 so 动态链接库依赖的问题,这点是非常值得称赞的。
 
显示指定静态编译方法
在Docker化的今天, 我们经常需要静态编译一个Go程序,以便方便放在Docker容器中。 即使你没有引用其它的第三方包,只是在程序中使用了标准库net,你也会发现你编译后的程序依赖glic,这时候你需要glibc-static库,并且静态连接。

不同的Go版本下静态编译方式还有点不同,在go 1.10下, 下面的方式会尽可能做到静态编译:
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' .

原文: http://suo.im/6d3eun  

告诉你真实的软件开发Bug产生过程

互联网资讯OS小编 发表了文章 • 0 个评论 • 108 次浏览 • 2020-04-25 22:55 • 来自相关话题

领导:修个房子。

程序员:好的,马上开始打地基!

领导:你看那隔壁那木房子就没有打地基,不要在小事上浪费时间,一个月水平面上面什么都看不到,你kpi不要了?

这是敏捷开发。


一层房子修好。

领导:我觉得两层楼的视野好,再加一层。

程序员:可是我们没有地基,重新打地基要时间……

领导:你一楼都修好了,照着再修个一模一样二楼很难?还要很多时间?

这是高速版本迭代。


二楼修好。

领导:天天走路累死了,你再修个电梯。

程序员:可是……

领导:没什么可是的,地基不稳?就在房子边上搭个电梯就行了嘛,不稳拿根木棍撑一下,这都不懂?

这是版本优化。


电梯修好。

领导:我觉得顶楼再加个游泳池就好了。

程序员:这个结构行业翘楚的房子也不支持呀!

领导:那不正显得我们牛逼么?修快点,夏天要来了。

这是快速功能追加。


游泳池修好,看着摇摇欲坠的房子,程序员跑路了,领导找来新人继续。

领导:我觉得游泳池水不够满,你加点的,一楼光线不好你在墙上打个窗户。

新人:好的,没问题领导,马上加一桶水,马上砸墙

这是打补丁。


房子塌了,电梯倒了,游泳池垮了……

领导:真是个废物,就让他加桶水,居然能把房子弄倒了,你说这是多没用?

新人:我真的就加了桶水,我怎么知道为什么。

这是软件莫名崩溃。
 

来源: 知乎
作者:哒柏
链接:http://suo.im/6kaAEi 查看全部
领导:修个房子。

程序员:好的,马上开始打地基!

领导:你看那隔壁那木房子就没有打地基,不要在小事上浪费时间,一个月水平面上面什么都看不到,你kpi不要了?

这是敏捷开发


一层房子修好。

领导:我觉得两层楼的视野好,再加一层。

程序员:可是我们没有地基,重新打地基要时间……

领导:你一楼都修好了,照着再修个一模一样二楼很难?还要很多时间?

这是高速版本迭代


二楼修好。

领导:天天走路累死了,你再修个电梯。

程序员:可是……

领导:没什么可是的,地基不稳?就在房子边上搭个电梯就行了嘛,不稳拿根木棍撑一下,这都不懂?

这是版本优化


电梯修好。

领导:我觉得顶楼再加个游泳池就好了。

程序员:这个结构行业翘楚的房子也不支持呀!

领导:那不正显得我们牛逼么?修快点,夏天要来了。

这是快速功能追加


游泳池修好,看着摇摇欲坠的房子,程序员跑路了,领导找来新人继续。

领导:我觉得游泳池水不够满,你加点的,一楼光线不好你在墙上打个窗户。

新人:好的,没问题领导,马上加一桶水,马上砸墙

这是打补丁


房子塌了,电梯倒了,游泳池垮了……

领导:真是个废物,就让他加桶水,居然能把房子弄倒了,你说这是多没用?

新人:我真的就加了桶水,我怎么知道为什么。

这是软件莫名崩溃
 


来源: 知乎
作者:哒柏
链接:http://suo.im/6kaAEi


AIOps根因分析最佳实践

运维技术OS小编 发表了文章 • 0 个评论 • 201 次浏览 • 2020-04-14 13:42 • 来自相关话题

随着基础架构和软件环境变得越来越复杂,检测性能或可用性问题的根因变得越来越具有挑战性。幸运的是,迎接挑战的是一类新的工具和一种新的策略:AIOps。

什么是根因分析?
在IT中,根因分析是确定硬件或软件问题的根本问题原因是什么的过程。

根因分析很重要,因为在许多情况下,有多个可能的问题原因,而且从问题本身来看,原因并不明显。例如,如果应用程序开始响应缓慢,则仅凭这些信息就很难知道问题的原因是否是应用程序本身编写的糟糕的代码,还是托管应用程序的操作系统存在的问题,还是文件系统存在问题。应用程序正在使用,应用程序所依赖的网络或存储基础结构出现问题或其他原因。也可能有多个潜在问题在起作用。

为什么当前根因分析尤其重要
从前,根因分析相对简单,因为IT团队需要管理的硬件和软件层较少。物理基础架构和硬件环境之间也几乎没有抽象。因此,如果监控软件检测到磁盘性能问题,则可以相对确定磁盘本身或用于格式化磁盘的文件系统是根本问题。

但是,今天,我们依赖高度动态的多层软件定义环境。映射这些环境中所有组件之间的关系非常困难,尤其是因为配置不断变化。很难解释在环境的一层中表现出来的问题与其他层之间的关系。

如今,存储性能问题的根因可能不一定是物理磁盘或本地文件系统,还可能是使存储可供远程系统使用的网络或分布式文件系统。也可能是提供存储的虚拟化网络。

充分利用AIOps进行根因分析
部分原因是由于现代环境中根因分析的困难, AIOps变得如此重要。通过使用机器学习自动映射和解释复杂的环境和因果关系,AIOps可以帮助IT团队比仅依靠手动分析更快地找到性能或可用性问题的根源。简单地使用AIOps工具将大大提高您的根本原因分析能力。

就是说,您可以采取一些步骤来确保充分利用AIOps辅助的根本原因分析。它们包括以下内容。

1. 记住,配置快速变更,根因也会随之变更

在瞬息万变的现代环境中进行根因分析的棘手事情之一是,一次构成根本问题的原因可能在下一时刻改变。应用程序性能缓慢的根本原因可能是网络拥塞,但随着网络流量模式和存储系统负载的变化,下一阶段将变为IO瓶颈。

AIOps工具可以帮助解决这些变化,但是对于人类工程师而言,重要的是要记住根因是可以改变的。不要认为核心问题是一成不变的。

2. 考虑自动响应

AIOps的另一个关键功能是它使软件工具可以采取自动措施来解决问题。尽管并不是在每种情况下都自动响应是正确的解决方案(例如,您可能希望让人工工程师在进行重大变更之前先进行审查),但对于更简单的问题的自动响应可以有效地帮助确保您不仅识别根因可以快速解决,也可以在最终给用户造成严重问题之前解决它们。

3. 不要假设只有一个根因

如上所述,软件或硬件问题的原因可能是多个问题。停止响应的应用程序可能会这样做,因为代码编写得不好,无法使应用程序从意外的网络错误中恢复;在这种情况下,应用程序代码和网络问题都是此问题的根因。

这里的关键要点是,一方面,在执行根因分析时,您应努力将辅助问题与根因区分开,但您不应排除可能存在两个或多个核心潜在问题的可能性。

4. 力求与环境无关的根本原因分析

理想情况下,根因分析工作流程应对任何类型的基础架构或环境均有效。如果您依赖仅支持特定类型的环境或基础架构的监控或分析工具(例如来自特定云供应商的工具或仅针对一种操作系统设计的工具),则不会发生这种情况。

此处的教训是,您应该寻找AIOps工具 ,这些工具可以协助对任何类型的基础结构进行根本原因分析。
 
英文原文:http://suo.im/64aCgc  查看全部
随着基础架构和软件环境变得越来越复杂,检测性能或可用性问题的根因变得越来越具有挑战性。幸运的是,迎接挑战的是一类新的工具和一种新的策略:AIOps。

什么是根因分析?
在IT中,根因分析是确定硬件或软件问题的根本问题原因是什么的过程。

根因分析很重要,因为在许多情况下,有多个可能的问题原因,而且从问题本身来看,原因并不明显。例如,如果应用程序开始响应缓慢,则仅凭这些信息就很难知道问题的原因是否是应用程序本身编写的糟糕的代码,还是托管应用程序的操作系统存在的问题,还是文件系统存在问题。应用程序正在使用,应用程序所依赖的网络或存储基础结构出现问题或其他原因。也可能有多个潜在问题在起作用。

为什么当前根因分析尤其重要
从前,根因分析相对简单,因为IT团队需要管理的硬件和软件层较少。物理基础架构和硬件环境之间也几乎没有抽象。因此,如果监控软件检测到磁盘性能问题,则可以相对确定磁盘本身或用于格式化磁盘的文件系统是根本问题。

但是,今天,我们依赖高度动态的多层软件定义环境。映射这些环境中所有组件之间的关系非常困难,尤其是因为配置不断变化。很难解释在环境的一层中表现出来的问题与其他层之间的关系。

如今,存储性能问题的根因可能不一定是物理磁盘或本地文件系统,还可能是使存储可供远程系统使用的网络或分布式文件系统。也可能是提供存储的虚拟化网络。

充分利用AIOps进行根因分析
部分原因是由于现代环境中根因分析的困难, AIOps变得如此重要。通过使用机器学习自动映射和解释复杂的环境和因果关系,AIOps可以帮助IT团队比仅依靠手动分析更快地找到性能或可用性问题的根源。简单地使用AIOps工具将大大提高您的根本原因分析能力。

就是说,您可以采取一些步骤来确保充分利用AIOps辅助的根本原因分析。它们包括以下内容。

1. 记住,配置快速变更,根因也会随之变更

在瞬息万变的现代环境中进行根因分析的棘手事情之一是,一次构成根本问题的原因可能在下一时刻改变。应用程序性能缓慢的根本原因可能是网络拥塞,但随着网络流量模式和存储系统负载的变化,下一阶段将变为IO瓶颈。

AIOps工具可以帮助解决这些变化,但是对于人类工程师而言,重要的是要记住根因是可以改变的。不要认为核心问题是一成不变的。

2. 考虑自动响应

AIOps的另一个关键功能是它使软件工具可以采取自动措施来解决问题。尽管并不是在每种情况下都自动响应是正确的解决方案(例如,您可能希望让人工工程师在进行重大变更之前先进行审查),但对于更简单的问题的自动响应可以有效地帮助确保您不仅识别根因可以快速解决,也可以在最终给用户造成严重问题之前解决它们。

3. 不要假设只有一个根因

如上所述,软件或硬件问题的原因可能是多个问题。停止响应的应用程序可能会这样做,因为代码编写得不好,无法使应用程序从意外的网络错误中恢复;在这种情况下,应用程序代码和网络问题都是此问题的根因。

这里的关键要点是,一方面,在执行根因分析时,您应努力将辅助问题与根因区分开,但您不应排除可能存在两个或多个核心潜在问题的可能性。

4. 力求与环境无关的根本原因分析

理想情况下,根因分析工作流程应对任何类型的基础架构或环境均有效。如果您依赖仅支持特定类型的环境或基础架构的监控或分析工具(例如来自特定云供应商的工具或仅针对一种操作系统设计的工具),则不会发生这种情况。

此处的教训是,您应该寻找AIOps工具 ,这些工具可以协助对任何类型的基础结构进行根本原因分析。
 
英文原文:http://suo.im/64aCgc 

AIOPS是什么,它与AI有什么关系?

运维技术OS小编 发表了文章 • 0 个评论 • 122 次浏览 • 2020-04-13 14:45 • 来自相关话题

 
现如今,AI 这个词已经被玩坏了。很多公司都声称自己在做 AI,但其实并没有。不过有另外一种新兴的 AI,各种类型的 IT 企业倒是可以尝试,而且完全不需要人工参与。

AIOps,也就是基于算法的 IT 运维(Algorithmic IT Operations),是由 Gartner 定义的新类别,源自业界之前所说的 ITOA(IT Operations and Analytics)。我们已经到达了这样的一个时代,数据科学和算法正在被用于自动化传统的 IT 运维任务和流程。算法被集成到工具里,帮助企业进一步简化运维工作,把人类从耗时又容易出错的流程中解放出来。人们不再需要在遗留的管理系统中定义和管理无穷无尽的规则和过滤器。

在过去的几年间,一些新技术不断涌现,利用数据科学和机器学习来推进日益复杂的企业数字化进程,“AIOps”(Algorithmic IT Operations)因此应运而生。Gartner 的报告宣称,到 2020 年,将近 50% 的企业将会在他们的业务和 IT 运维方面采用 AIOps,远远高于今天的 10%。

为了更好地理解 AIOps 和 AI 的区别,我们需要从头说起。
 

AI 简史

AI 一词用于描述机器(或软件)模拟人类认知的过程。也就说,机器学习像人类一样思考。40 年代,Alan Turing 掀起了 AI 热潮,但受限于计算机的计算能力,也只发展到今天的这个阶段。

问题是,我们为什么要让机器模仿人类?而为什么有些 AI 应用程序会比其他的更成功?发展 AI 的目的在于解决人类的问题,所以我们会看到像自动驾驶汽车、行为分析这类复杂的解决方案。

话说回来,IT 运维环境有一些不一样的地方。我们不会直接管理人类,我们与应用程序和基础设施打交道。而且它们可能更加复杂和不可预测,因为它们不是人类。
 

人类思维与机器思维

AIOps 的不同之处在这里体现出来。AIOps 的解决方案专注于解决问题,而且是通过使用基于算法的技术来高度模仿人类(而且以更快的速度和更大的规模)。算法的效率提升了 AIOps 的价值,而相对于人类的智慧——虽然是无限的,但不如机器来得高效。

当然,人类也能进行高效的 IT 运维。AIOps 的目的是为了让我们的生活变得更美好,但是当人类与 AIOps 参合在一起,它们之间的界限就会变得模糊。高级的 AIOps 会使用神经网络技术,它会向运维人员学习,然后尝试消除无聊的重复性劳动。
 

未来的公司

 
为什么公司需要 AIOps?现代的 IT 环境已经无比的复杂,而且千变万化,需要我们花费大量的时间和资源去监控、去诊断问题、去解决问题。很多公司处于被动的地位。但是如果他们使用了 AIOps,他们就可以利用先进的算法,花更多时间在其他更有意义的工作上,而不是重复地解决相同的问题,或者花时间管理规则和过滤器。

我们所说的规则,可以把它们简单地描述为“如果是这样那么就这么做”,它们能够应付简单的场景,但是很难扩展。相反,算法和机器学习提供了更加灵活的表达方式,不仅强大,而且健壮,能够应付不断变化的需求。这将带来更高的效率和更低的成本。对于厂商来说,他们面临的挑战在于将整个技术方案打包,避免把用户暴露于底层的复杂性当中。光是提供工具是不够的,企业需要招聘数据科学家而不仅仅是工程师。
 

前行之路

借助智能算法的技术优势,原先人工需要几个小时完成的任务现在通过自动化可以在几秒钟内完成,而且能够得到更好的结果。传统的 IT 运维需要管理大量的告警,极大地分散了企业的注意力,他们需要花很多时间解决无聊的问题,没有时间用于创新。使用 AIOps 可以解决这些问题,把运维人员从纷繁复杂的告警和噪音中解脱出来。各个行业的企业正在采用 AIOps,他们使用这项技术来改进客户的数字体验——银行、娱乐、交通、零售,甚至政府。

尽管 AIOps 还是一个新名词,但并不代表它只是未来的一种趋势而已。在这个数字的年代,任何使用传统技术来管理机器数据的组织要么忽略了信息的价值,要么已经让他们的运维团队不堪重负。随着数据的暴涨,CIO 们应该快速拥抱 AIOps。传统 AI 仍然会在某些领域发挥它的作用,而 AIOps 将为企业带来最直接最深远的价值。
 
文章来自微信公众号:高效开发运维 查看全部
 
现如今,AI 这个词已经被玩坏了。很多公司都声称自己在做 AI,但其实并没有。不过有另外一种新兴的 AI,各种类型的 IT 企业倒是可以尝试,而且完全不需要人工参与。

AIOps,也就是基于算法的 IT 运维(Algorithmic IT Operations),是由 Gartner 定义的新类别,源自业界之前所说的 ITOA(IT Operations and Analytics)。我们已经到达了这样的一个时代,数据科学和算法正在被用于自动化传统的 IT 运维任务和流程。算法被集成到工具里,帮助企业进一步简化运维工作,把人类从耗时又容易出错的流程中解放出来。人们不再需要在遗留的管理系统中定义和管理无穷无尽的规则和过滤器。

在过去的几年间,一些新技术不断涌现,利用数据科学和机器学习来推进日益复杂的企业数字化进程,“AIOps”(Algorithmic IT Operations)因此应运而生。Gartner 的报告宣称,到 2020 年,将近 50% 的企业将会在他们的业务和 IT 运维方面采用 AIOps,远远高于今天的 10%。

为了更好地理解 AIOps 和 AI 的区别,我们需要从头说起。

 


AI 简史


AI 一词用于描述机器(或软件)模拟人类认知的过程。也就说,机器学习像人类一样思考。40 年代,Alan Turing 掀起了 AI 热潮,但受限于计算机的计算能力,也只发展到今天的这个阶段。

问题是,我们为什么要让机器模仿人类?而为什么有些 AI 应用程序会比其他的更成功?发展 AI 的目的在于解决人类的问题,所以我们会看到像自动驾驶汽车、行为分析这类复杂的解决方案。

话说回来,IT 运维环境有一些不一样的地方。我们不会直接管理人类,我们与应用程序和基础设施打交道。而且它们可能更加复杂和不可预测,因为它们不是人类。

 


人类思维与机器思维


AIOps 的不同之处在这里体现出来。AIOps 的解决方案专注于解决问题,而且是通过使用基于算法的技术来高度模仿人类(而且以更快的速度和更大的规模)。算法的效率提升了 AIOps 的价值,而相对于人类的智慧——虽然是无限的,但不如机器来得高效。

当然,人类也能进行高效的 IT 运维。AIOps 的目的是为了让我们的生活变得更美好,但是当人类与 AIOps 参合在一起,它们之间的界限就会变得模糊。高级的 AIOps 会使用神经网络技术,它会向运维人员学习,然后尝试消除无聊的重复性劳动。

 


未来的公司


 
为什么公司需要 AIOps?现代的 IT 环境已经无比的复杂,而且千变万化,需要我们花费大量的时间和资源去监控、去诊断问题、去解决问题。很多公司处于被动的地位。但是如果他们使用了 AIOps,他们就可以利用先进的算法,花更多时间在其他更有意义的工作上,而不是重复地解决相同的问题,或者花时间管理规则和过滤器。

我们所说的规则,可以把它们简单地描述为“如果是这样那么就这么做”,它们能够应付简单的场景,但是很难扩展。相反,算法和机器学习提供了更加灵活的表达方式,不仅强大,而且健壮,能够应付不断变化的需求。这将带来更高的效率和更低的成本。对于厂商来说,他们面临的挑战在于将整个技术方案打包,避免把用户暴露于底层的复杂性当中。光是提供工具是不够的,企业需要招聘数据科学家而不仅仅是工程师。

 


前行之路


借助智能算法的技术优势,原先人工需要几个小时完成的任务现在通过自动化可以在几秒钟内完成,而且能够得到更好的结果。传统的 IT 运维需要管理大量的告警,极大地分散了企业的注意力,他们需要花很多时间解决无聊的问题,没有时间用于创新。使用 AIOps 可以解决这些问题,把运维人员从纷繁复杂的告警和噪音中解脱出来。各个行业的企业正在采用 AIOps,他们使用这项技术来改进客户的数字体验——银行、娱乐、交通、零售,甚至政府。

尽管 AIOps 还是一个新名词,但并不代表它只是未来的一种趋势而已。在这个数字的年代,任何使用传统技术来管理机器数据的组织要么忽略了信息的价值,要么已经让他们的运维团队不堪重负。随着数据的暴涨,CIO 们应该快速拥抱 AIOps。传统 AI 仍然会在某些领域发挥它的作用,而 AIOps 将为企业带来最直接最深远的价值。
 
文章来自微信公众号:高效开发运维

添加PHP的readline模块报错configure: error: Please reinstall libedit

回复

运维技术Geek小A 回复了问题 • 1 人关注 • 3 个回复 • 177 次浏览 • 2020-04-10 19:42 • 来自相关话题

添加扩展PHP模块的时候报错

运维技术采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 100 次浏览 • 2020-04-10 16:03 • 来自相关话题

Ubuntu下编译PHP报错ld: final link failed: nonrepresentable section on output

运维技术采菊篱下 回复了问题 • 2 人关注 • 2 个回复 • 232 次浏览 • 2020-04-10 11:44 • 来自相关话题

编译安装libXpm报错

运维技术Nock 回复了问题 • 2 人关注 • 1 个回复 • 137 次浏览 • 2020-04-09 10:39 • 来自相关话题

Centos下执行git clone报错

运维技术Nock 回复了问题 • 2 人关注 • 1 个回复 • 109 次浏览 • 2020-04-08 23:37 • 来自相关话题