快速提升单元覆盖率

最近到新公司,接手了几十个老项目。由于项目特殊需要,需要快速将一个模块的单元测试覆盖率提升到80%以上。

怀着忐忑的心情看了一下,该模块居然还有一个单元测试,整体覆盖率为0,欲哭无泪啊。

手工写是来不及了,那就想办法自动生成吧。找了一下,最终决定采用EvoSuite。

EvoSuite有多种方式可以配置,包括命令行模式、Maven插件模式以、Eclipse插件模式、IDEA插件模式等。

一、maven模式
1、修改POM文件,在对应位置添加相关内容

<properties>
	<evosuiteVersion>1.0.6</evosuiteVersion>
</properties>

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.12</version>
		<scope>test</scope>
	</dependency>
	<dependency>
		<groupId>org.evosuite</groupId>
		<artifactId>evosuite-standalone-runtime</artifactId>
		<version>${evosuiteVersion}</version>
		<scope>test</scope>
	</dependency>
</dependencies>

<build>
	<pluginManagement>
		<plugins>
			<plugin>
				<groupId>org.eclipse.m2e</groupId>
				<artifactId>lifecycle-mapping</artifactId>
				<version>1.0.0</version>
				<configuration>
					<lifecycleMappingMetadata>
						<pluginExecutions>
							<pluginExecution>
								<pluginExecutionFilter>
									<groupId>org.apache.maven.plugins</groupId>
									<artifactId>maven-compiler-plugin</artifactId>
									<versionRange>[2.5,)</versionRange>
									<goals>
										<goal>prepare</goal>
									</goals>
								</pluginExecutionFilter>
								<action>
									<ignore />
								</action>
							</pluginExecution>
						</pluginExecutions>
					</lifecycleMappingMetadata>
				</configuration>
			</plugin>
		</plugins>
	</pluginManagement>
	<plugins>
		<plugin>
			<groupId>org.evosuite.plugins</groupId>
			<artifactId>evosuite-maven-plugin</artifactId>
			<version>${evosuiteVersion}</version>
			<executions>
				<execution>
					<goals>
						<goal>prepare</goal>
					</goals>
					<phase>process-test-classes</phase>
				</execution>
			</executions>
		</plugin>

		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.17</version>
			<configuration>
				<properties>
					<property>
						<name>listener</name>
						<value>org.evosuite.runtime.InitializingListener</value>
					</property>
				</properties>
			</configuration>
		</plugin>

		<!--plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>build-helper-maven-plugin</artifactId>
			<version>1.8</version>
			<executions>
				<execution>
					<id>add-test-source</id>
					<phase>generate-test-sources</phase>
					<goals>
						<goal>add-test-source</goal>
					</goals>
					<configuration>
						<sources>
							<source>.evosuite/evosuite-tests</source>
						</sources>
					</configuration>
				</execution>
			</executions>
		</plugin-->

		<plugin>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>3.8.1</version>
			<configuration>
				<source>1.8</source>
				<target>1.8</target>
			</configuration>
		</plugin>
	</plugins>
</build>

2、生成单元测试

mvn -DmemoryInMB=4000 -Dcores=4 evosuite:generate test

#生成的单元测试在
#.evosuite/best-tests
#拷贝到正确的路径就可以了

二、命令行模式
1、下载evosuite-1.0.6.jar包

Downloads

2、收集项目依赖,把evosuite-1.0.6.jar也放入target/dependency文件夹

mvn dependency:copy-dependencies

3、生成单元测试

cd target/dependency
java -jar evosuite-1.0.6.jar -help
java -Duse_separate_classloader=false -jar evosuite-1.0.6.jar -projectCP YOUR_CLASS_PATH -generateSuite -target ..\classes

#生成的单元测试在
#target/dependency/evosuite-tests
#拷贝到正确的路径就可以了

三、Eclipse插件模式
在eclipse中安装evosuite插件,需要额外的插件地址:
http://www.evosuite.org/update

四、单元覆盖率
1、插件安装
在eclipse中搜索并安装EclEmma Java Code Coverage插件,直接搜索即可

2、修改class loader配置

#默认使用单独的class loader,覆盖率会为0
separateClassLoader = true
#全局替换为
separateClassLoader = false

3、然后在项目上,右键,Coverage as-》JUnit Test
就可以看到覆盖率了哦。
我试过两个项目,一个简单的项目,覆盖率为95以上。
一个复杂一些的Web项目,覆盖率仅为30%左右。

五、总结
生成的单元测试,实际上没有什么维护性,如何用于生产环境,待探索。

故障恢复

故障恢复
之前做个一个折中的处理方案,类似于快速接收,批处理,反馈处理状态。之所以这样处理,是因为合作机构IT水平参差不齐,而且配合程度不高,如果把数据接收+处理+反馈放到一起的话,一旦有错误,就要麻烦对方重新推送最新数据,或者自己脚本重新处理数据,而且一天峰值十分明显,峰值时根本来不及处理数据。
1、数据接收阶段,采用了快速失败策略。一旦数据落库文件落盘,就返回成功,反之失败。
2、数据处理阶段,会进行重试,三次后进入失败队列
3、进入失败队列后,会通知运维和开发,去看下数据什么问题。有时会把文件手工处理一下,再重试。如果实在无法处理,就线下通知合作方相关人员如何修改数据。
4、数据处理成功后或彻底失败后,发送处理结果给合作方。

这种方式,在对合作方约束很小、合作方缺乏技术支持、项目前期阶段、以快速开展业务为优先考量时,可以尝试一下。后面自己做起来后,就可以要求对方,做一些统一要求了。

限流和降级
之前在一个大量读写小文件服务的入口处,用过令牌桶限制访问量,防止IO过高。问题是每秒要发放发放多少令牌,最后是慢慢试出来的。

后面微服务时代就是中规中矩的限流,降级和熔断了。但降级和熔断,是通过HTTP状态码进行判断的,有些后知后觉了。

零信任网络
一个团队去完成一个任务,如果彼此信任,相互配合就会很流畅,沟通成本会很低,任务推进也会很顺畅。比如几个知根知底的伙伴去创业,一个眼神可能就懂了。
一群互不信任的人去完成一个任务,哪怕每个人都很努力,但经常感觉别人掣肘,吵来吵去,任务止步不前。一个流动率高,甩锅成风的组织,便是如此。

代码也是如此,如果我们假设代码是可信的,直接拉取镜像就行了。
如果假设代码是不可信的,开发提交代码后,要各种引擎扫描,扫描通过后,流水线打包镜像。同时还要提交各类材料如测试报告,越权测试报告,渗透测试报告,压力测试报告,代码审核报告等等相互佐证代码没有问题,然后发布。
这样先不说要多少资源支持,单说发布,就从十几秒变成了十几分钟,甚至几十分钟。

服务也是如此,如果假设服务是可信的,不要加任何控制,就可以相互访问。
如果假设服务不可信,就要各种验证,网络端口是否允许访问,token是否正确,双向证书过了没,是否有服务访问权限,是否有数据权限,是否符合流量控制要求等等。
先不说做需要多少资源支持,单说服务性能,从几十毫秒一下到了几百毫秒。

那做这些值吗?值!
但要符合自己的情况,不能太过,绑了自己的手脚!

零信任网络安全
我认为边界安全模型和零信任模型会长期共存,边界安全模型毕竟更成熟,而且在资源隔离程度上,远高于零信任模型。istio们并没有提供边界模型的一些组件,比如杀毒,比如入侵检测,比如蜜罐,比如上帝视角的规则控制等。而且istio们本身也有被入侵的可能,所以不能只依赖这一个层面的安全管控,而是立体的安全管控。

可观测性
单体程序时代,类似于一个办公大楼,有了问题,告诉管理员门牌号和具体事情就行了,管理员就可以乘电梯过来解决问题。
只要在日志里输出一下,哪个方法,做了哪个任务或出了什么问题,用日志工具就可以统计到处理速度或快速定位到问题了。

微服务时代,类似于管理城市物流。要提出问题,我们必须说明,那条街,哪个门牌号,几单元,有什么需求。工作人员上门时,要看下地图,什么路线过去最快,遇到堵车怎么办,小区不让进怎么办,然后才能到顾客这边提供服务。数据链路就像城市地图,监控就像地图上的流量,而日志必须还原到这张地图上,才知道哪个交叉口或哪个大楼哪里出了问题。
所以,我们要花必要的精力,去做全链路,绘制这个地图。所以我们要收集度量信息,去监控哪里流量红了,哪里彻底堵车了。只凭日志,是无法快速定位问题的,这个交叉口堵车,问题可能出在三公里之外,一个交叉口一个交叉口查过去,太慢了。

流量大了,堵车是必然的。只有做好可观测性,才能快速疏导交通,做到事半功倍。

日志
个人觉得,如何正确的记录日志,用何规则做日志分级,要记录哪些东西,比用什么技术栈分析日志重要的多。老师能否分享一下,日志规范如何在团队中落地呢?

有两种情况,多记录一些日志有好处的。一类是部署于第三方的系统,宕机时要多记录日志,最好有dump文件,利于排查问题。第二类是跨公司做集成对接,输入输出一般都会记得很清楚,为了防止扯皮。

聚合度量
主要监控了服务请求,JVM,服务器的一些指标。但服务请求方面,做的还很基础,有较大提升空间。

Ubuntu18升级到20

1、升级准备
做好资料备份

2、开始升级

# 更新Ubuntu18
sudo apt get update
sudo apt get upgrade
sudo apt autoremove

# 查看有哪些版本可以升级
sudo do-release-upgrade -c
sudo do-release-upgrade -d -c

# 升级到Ubuntu20
sudo do-release-upgrade -d

# 系统会自动升级,升级后,桌面操作快乐很多
# 现阶段有个问题,就是升级后,桌面快捷方式都不能使用了,不知道怎么回事

3、替换国内源

sudo vi /etc/apt/sources.list
deb http://mirrors.163.com/ubuntu/ focal main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ focal-security main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ focal-updates main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ focal-proposed main restricted universe multiverse
deb http://mirrors.163.com/ubuntu/ focal-backports main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ focal main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ focal-security main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ focal-updates main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ focal-proposed main restricted universe multiverse
deb-src http://mirrors.163.com/ubuntu/ focal-backports main restricted universe multiverse

4、禁用自动更新

# 1都改为0
sudo vi /etc/apt/apt.conf.d/10periodic
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";

蓝牙鼠标支持双系统

操作系统与蓝牙鼠标之间的配对,是通过三个关键值完成的:
本机蓝牙ID,鼠标蓝牙ID,LinkKey
蓝牙鼠标在配对后,连接电脑蓝牙设备时,三个值必须一致,双方才能连接成功。
对于单系统来说不会引起什么问题,但对于双系统的电脑来说,就会有问题了。

比如,你是Windows和Ubuntu双系统,或Windows和Mac双系统。
在第一个系统中配对后,会生成一个LinkKey,鼠标就可以在第一个系统中连接成功,但无法在第二个系统中连接成功。
在第二个系统配对后会生成另外一个LinkKey,鼠标就可以在第二个系统中连接成功,但无法在第一个系统中连接成功。
所以,要蓝牙鼠标支持双系统,就要把两个系统的LinkKey改为一致。

一、首先是Windows和Ubuntu双系统:
1、在Windows下配对鼠标
2、在Ubuntu下配对鼠标
3、在Ubuntu下查找配对后的LinkKey

#3.1、定位你的设备配置文件
#一般来说本机蓝牙ID只会有一个,是以:分割的一长串十六机制数字
#蓝牙设备,就是全部配过对的蓝牙设备,可以通过查看info文件判断哪个是你的蓝牙鼠标
sudo vi /var/lib/bluetooth/本机蓝牙ID/鼠标蓝牙ID/info
#3.2、找到LinkKey
#找到下面部分,并记录下来
[linkkey]
key=16位16进制数字

4、重启进入Windows

#4.1、运行命令regedit,打开注册表编辑器
#4.2、定位到下面的位置,其中:
#本机蓝牙ID与Linux下一致,只是没有:分割
#鼠标蓝牙ID与Linux下一致,只是没有:分割
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\本机蓝牙ID
鼠标蓝牙ID=16位16进制数字
#4.3、修改LinkKey,使其与Ubunt下LinkKey一致

5、重新连接蓝牙鼠标试试,是不是两个系统都可以了?

此外,由于Ubuntu默认BIOS中是UTC时间,而Windows默认BIOS是本地时区时间,所以重启后,时间会不一致,比如东八区会相差8小时。可以通过将Ubuntu的BIOS时间也设置为本地时区来解决:

sudo timedatectl set-local-rtc 1

二、然后是Windows和Mac双系统:
1、在Windows下配对鼠标
2、在Mac下配对鼠标
3、在Mac下查找配对后的LinkKey

sudo defaults read /private/var/root/Library/Preferences/blued.plist
#找到Linkkey【一串16位16进制数字】,并记录下来

4、计算Windows的Linkkey

#4.1、假设Mac下的LinkKey为
#98542ff9 88e19449 475250e1 3943255b
#4.2、按每两个数字进行分组,然后从后向前倒序排列,就可以得到Windows下的LinkKey
#空格是为了方便大家查看才添加的
#5b254339 e1505247 4994e188 f92f5498

5、重启进入Windows

#4.1、运行命令regedit,打开注册表编辑器
#4.2、定位到下面的位置,其中:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\本机蓝牙ID
鼠标蓝牙ID=16位16进制数字
#4.3、修改LinkKey,使其与计算的到的LinkKey一致

6、重新连接蓝牙鼠标试试,是不是两个系统都可以了?

三、上面的都好烦,有没有其他办法?
1、使用有线鼠标
2、使用带有接收器的蓝牙鼠标

Ubuntu安装Nvidia驱动

1、检查显卡型号

#查看显卡型号
lshw -numeric -C display

#查看对应显卡驱动的版本
https://www.nvidia.com/Download/index.aspx

2、安装驱动
2.1、Ubuntu自动安装(适用于不太新的显卡)

sudo ubuntu-drivers devices
sudo ubuntu-drivers autoinstall

2.2、手动安装(适用于比较新的显卡)

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
sudo apt-get install

3、此外如果你的电脑BIOS支持Security Boot,需要设置密码才能用非官方驱动,如果设备环境相对可控安全级别没有这么高,可以考虑关闭这个功能。
否则,出现的情况就是Ubuntu无法加载该驱动,比如CUI登录正常,但一启动GUI界面,就会自动关机。这个有些坑,我重装了3遍才发现。

Apache2配置SSL证书

一、申请证书
各大云厂商均有销售,如果没有特殊需求买最便宜的或免费的,需要做域名验证,按指引做好验证即可
申请后会得到三个文件,保管好,不要给别人
ca.crt、server.crt、server.key
将这三个文件拷贝到/etc/apache2/ssl/

二、启用https
1、apache2启用ssl模块

sudo apt-get install openssl
sudo a2enmod ssl

2、配置ssl虚拟站点

# 建立软连接
sudo ln -s /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-enabled/001-default-ssl.conf

# 编辑https配置文件
sudo vi /etc/apache2/sites-enabled/001-default-ssl.conf
# 修改下面三行
SSLCertificateFile       /etc/apache2/ssl/server.crt
SSLCertificateKeyFile    /etc/apache2/ssl/server.key
SSLCertificateChainFile  /etc/apache2/ssl/ca.crt

3、重启apache服务

# 重启服务
sudo systemctl apache2 restart
# 查看状态
sudo systemctl status apache2.service

4、登录wordpress后台,修改网站地址为https地址

5、此时应该就可以用https进行访问了

三、设置http重定向到https
1、启动重定向模块

sudo a2enmod rewrite

2、设置http重定向

# 编辑http配置文件
sudo vi /etc/apache2/sites-available/000-default.conf 
# 在需要重定向的VirtualHost中,增加下面三行
<VirtualHost *:80>
    RewriteEngine on
    RewriteCond %{HTTPS} !=on
    RewriteRule ^(.*) https://%{SERVER_NAME}$1 [L,R]
<\VirtualHost> 

3、重启apache服务

# 重启服务
sudo systemctl apache2 restart
# 查看状态
sudo systemctl status apache2.service

4、现在访问http地址,就会自动跳转到https地址了

备份还原Gitlab

1、查看gitlab版本

gitlab-rake gitlab:env:info
System information
...
GitLab information
Version:        12.2.8
...
GitLab Shell
Version:        9.3.0
...

2、备份gitlab

gitlab-rake gitlab:backup:create
#会在这个路径生成新的备份文件
/var/opt/gitlab/backups/XXX_gitlab_backup.tar

3、准备新服务器
在新服务器上安装相同版本的gitlab,并将备份文件拷贝到新服务器相同路径

4、还原

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-rake gitlab:backup:restore BACKUP=XXX
gitlab-ctl start  

5、验证

gitlab-rake gitlab:check SANITIZE=true

Synology DS418 Paly安装Docker

去年入手了DS418 Play,一直没时间弄,春节期间正好搞一下,把Docker功能开起来。

1、DS418 Play在应用商店是没有Docker,但可以用DS418或DS918的安装文件
到官网,下载得到Docker-x64-18.09.0-0506.spk。

https://www.synology.cn/zh-cn/support/download/DS918+#packages

2、通过管理软件,网页上传安装spk文件包

3、安装后,就可以在应用界面看到docker了

4、如果网络比较好,就可以直接在应用界面开启docker

5、我这边网络比较差,所以要下载镜像后,再上传到DS418 Play
5.1、开启DS418 Play的ssh功能
5.2、找一台网速好的机器

#拉取镜像
sudo docker pull gitlab/gitlab-ce
#导出镜像
sudo docker save -o gitlab-ce.img gitlab/gitlab-ce

5.3、把镜像拷贝到DS418 Play
5.4、SSH到DS418 Play,导入镜像

#SSH登录
ssh DS418PlayIP
#导出镜像
sudo docker load -i ~/PATH_TO_IMG/gitlab-ce.img

6、创建挂载路径

mkdir /volume2/gitlab/etc
mkdir /volume2/gitlab/log
mkdir /volume2/gitlab/data

7、创建容器

sudo docker run \
--detach \
--publish 9443:443 \
--publish 9080:80 \
--name gitlab \
--restart unless-stopped \
-v /volume2/gitlab/etc:/etc/gitlab \
-v /volume2/gitlab/log:/var/log/gitlab \
-v /volume2/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest

8、修改配置文件

vi /mnt/gitlab/etc/gitlab.rb

#配置gitlab上看到的项目地址
external_url 'http://群晖IP:9080'

#配置邮箱
gitlab_rails['gitlab_email_from'] = 'xxx@qq.com'
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.qq.com"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] = "xxx@qq.com"
gitlab_rails['smtp_password'] = "xxx"
gitlab_rails['smtp_domain'] = "qq.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = true

#关闭不需要的服务
prometheus['enable'] = false
prometheus_monitoring['enable'] = false
grafana['enable'] = false

9、刷新配置

sudo docker exec gitlab gitlab-ctl reconfigure

10、查看日志

sudo docker exec gitlab gitlab-ctl status
sudo docker exec gitlab gitlab-ctl tail gitaly

11、登录系统

http://群晖IP:9080
默认用户名为root,系统会自动提示修改密码

导致惨重代价的运维事故2020

2020年12月:Google Cloud全球服务中断
事件经过:12月14日,Google旗下的多项核心服务(包括YouTube、Gmail、Google Drive、Google Search)在全球范围内发生大规模宕机,持续约1小时。这是近5个月内Google发生的第3次全球性故障。
事故原因:内部基础设施组件故障(据推测为身份验证或负载均衡服务)。
造成损失:全球数亿用户无法访问关键生产力工具和娱乐内容,再次引发了企业界对公有云巨头服务稳定性的担忧。

2020年11月:亚马逊AWS美国东部区域宕机
事件经过:AWS Kinesis数据流式处理服务软件错误,引发连锁故障,导致大量依赖该服务的网站和应用瘫痪,持续超4小时。
事故原因:软件缺陷引发的运维故障。
造成损失:大量企业业务中断,AWS声誉受损,面临客户索赔。

2020年9月:特斯拉全球性宕机
事件经过:9月23日上午11点起,特斯拉系统遭遇全球性宕机,持续约4小时,多国车主无法通过手机App连接车辆,太阳能及储能电池用户无法监控系统状态,部分车主被锁车外、有人在充电桩处被困近两小时。
事故原因:系统级故障。
造成损失:具体经济损失未公布,严重影响车主正常用车体验,品牌形象和用户信任度遭受显著打击。

2020年8月:CenturyLink配置错误导致全球互联网中断
事件经过:美国互联网服务提供商CenturyLink因数据中心错误配置引发连锁反应,全球互联网流量下降3.5%,受影响服务包括Cloudflare、AWS、Garmin等,7小时后故障解决。
事故原因:BGP路由配置错误。
造成损失:成为有史以来最大互联网中断之一,全球大量服务无法正常访问。

2020年8月:Zoom视频会议中断
事件经过:8月24日,正值全球远程办公和在线教学高峰期,Zoom发生了部分服务中断,导致用户无法访问离线会议和在线视频会议,中断持续了3小时。
事故原因:Zoom仅在状态页面表示“找到并解决了问题”,未详细披露是代码缺陷还是容量规划问题。
造成损失:在用户依赖度最高的时期掉链子,严重影响了全球企业的线上会议、学校教学以及商务谈判的正常进行

2020年6月:T-Mobile 美国全国通信中断
事件经过:6月15日,T-Mobile美国网络遭遇了长达13个小时的全国性瘫痪。这是T-Mobile历史上持续时间最长、影响范围最广的一次中断,导致数百万用户无法拨打语音电话或发送短信。
事故原因:网络配置变更失误。起因是东南部一个第三方供应商的光纤电路故障,但由于T-Mobile自身的网络冗余设计失效,加上后续的负载均衡配置问题,导致IP池过载,最终引发全网崩溃。
造成损失:全美范围内的语音和短信服务中断;由于正值疫情期间,严重影响了用户的紧急通讯和正常生活,公司声誉受损。

2020年5月:AWS大规模服务中断
事件经过:AWS发生严重故障,影响Amazon.com等众多网站和服务。
事故原因:路由表配置错误,更新骨干网络时错误路由表形成流量黑洞。
造成损失:全球大量网站和APP数小时无法访问,重创电商及在线服务。

2020年4月:华为云大面积宕机
事件经过:4月10日,华为云登录及管理后台无法访问,北京、广州、上海等地用户受影响,宕机持续约3小时,故障修复后部分客户业务逐步恢复。
事故原因:部分主机异常,具体技术细节未公开。
造成损失:多家公司业务无法正常维持,影响业务连续性。

2020年4月:GitHub服务中断
事件经过:4月21日,微软旗下GitHub多个服务访问异常,持续一个半小时,是当月多次宕机事件之一。
事故原因:未公开披露具体原因。
造成损失:影响开发者源代码存储、提交及协作工作,干扰项目推进。

2020年3月:微软Azure美东数据中心服务中断
事件经过:3月3日,微软美国东部数据中心服务中断6小时,美国北部客户无法使用Azure云服务,最终通过重置冷却系统控制器、重启硬件恢复。
事故原因:冷却系统故障,楼宇自动化控制功能失灵导致气流减少,数据中心温度飙升影响设备性能。
造成损失:计算和存储实例无法访问,影响依赖该区域云服务的企业业务运转。

2020年3月:微软Teams服务中断
事件经过:3月16日,新冠疫情期间Teams平台涌入大量新用户,导致欧洲地区服务宕机2小时。
事故原因:服务支持能力不足,无法承载突发用户量激增压力。
造成损失:对依赖远程办公的企业造成较大影响,干扰正常办公秩序。

2020年3月:谷歌云平台服务中断
事件经过:3月26日,谷歌多个云服务无法访问,用户频繁遇到500、502错误代码,美国东部沿海地区用户受影响最严重。
事故原因:基础设施组件故障。
造成损失:大量用户无法正常使用谷歌云服务,业务推进受阻。

2020年3月:腾讯课堂系统崩溃
事件经过:3月4日,腾讯课堂出现登录失败问题,因凌晨系统升级时部分机器故障引发,当日8:30经紧急抢修恢复正常。
事故原因:系统升级操作不当,部分机器升级过程中出现故障。
造成损失:影响在线教育课程开展,干扰师生教学进度。

2020年2月:微盟员工恶意删库事故
事件经过:2月23日,微盟研发中心运维部核心人员贺某通过个人VPN登入内网跳板机,4分钟内删除服务器全部数据,致300余万用户无法使用SaaS产品,故障持续8天14小时。
事故原因:员工因个人精神、生活问题恶意破坏,滥用运维权限执行高危删除操作。数据最后在腾讯云的帮助下得以恢复。
造成损失:市值蒸发28亿,预计赔偿金1.5亿,直接经济损失2260余万元,含数据恢复费、商户赔偿费等。
小插曲:据悉,该工程师欠了网贷无力偿还,而且当天喝了不少酒,该工程师被判刑6年月。

Git06传输大repository失败

1、最近接手了一个项目,下载代码时,总会报错

git clone https://e.coding.net/xxx/xxx.git
error: RPC failed; curl 18 transfer closed with outstanding read data remaining

2、有建议说将缓存设置大一些,但没有用

#524288000单位为Byte,524288000B也就是 500MB
git config --global http.postBuffer 524288000

#1G
git config --global http.postBuffer 1048576000

3、最后将下载方式从https改为ssh方式就好了

ssh-keygen -t rsa -C "neohope@yahoo.com"
GIT_SSH_COMMAND="ssh -i /PATH_TO_ISA/xxx.rsa" git clone git@e.coding.net:xxx/xxx.git