1. 搜索所有含 node 名称的软件

1

yum list --enablerepo=remi | grep node

2. 指定 repo 源

1

yum install -y nodejs --enablerepo=nodesource

项目名称：XXXX
修订历史：

##

阿斯蒂芬

1 概述

1.1 术语

术语将贯穿需求、分析、设计、开发、测试、维护阶段，在整个软件生命周期中，参与者都将以统一的术语交流；
术语定义要求精确，严格，且勿模糊，含蓄；
术语一般是名词。

注意：如果在 PRD 文档中已经定义了某一个术语，建议在此处引用定义，以确保本文档的阅读者能够在一篇文档中就可以了解所有的关键术语。

1.2 需求背景

本项目的任务提出者，用户及实现该软件的部门；
该软件系统同其他系统或其他机构的基本关系；

1.3 目标

1.3.1 高可用目标

高可用目标主要包含性能、容量、可用率（主要是围绕 RTO/RPO）等；
容量及性能分析，主要定义目标容量、峰值、压测方案以及可能存在的瓶颈点及优化建议。

注：高可用各业务整体 RTO,RPO 目标，通过目标看单点（所有单点默认都不满足目标 RTO,RPO 要求）。

1.3.2 资金安全目标

资金安全防控的整体目标主要是控制风险敞口，原则上不允许超过 100 万，具体产品做具体分析，不能超过上述目标

2 系统构架与领域模型

2.1 定义系统整体架构

根据从相似系统或相似问题领域中获取的经验，定义备选构架和模型

2.2 定义系统运维部署架构

可以参考主站整体部署架构，对本项目涉及范围的部署架构进行说明

2.3 系统 1 领域模型

2.3.1 定义系统的领域模型

技术风险系分的领域模型，主要涉及免疫系统和海豹故障定位系统的领域模型
整体的技术风险研发工作，期望以 DDD 的思路进行风险分析设计，提供更好的扩展性和延续性
通过建设技术风险的领域模型，对业务功能领域对象进行技术风险层面的领域建模抽象，实现与业务系统的解耦和技术风险系统的持续架构演进

2.3.2 确定核心业务逻辑

确定领域模型中的核心规则，约束，平衡检查等

2.4 系统 2 领域模型

重复上述过程

3 业务边界分析

此处最好标明哪些业务用例是技术风险相关的，用于下面的风险基线分析。此时的用例既有可能是从需求分析阶段顺延下来的业务用例，也有可能存在为了达到业务目标，而挖掘出来的系统需求所对应的纯粹的系统用例。

3.1 业务用例边界

从用例的角度对业务边界和参与者进行界定
在这里可以画出业务用例图，明确业务用例边界，下面的系统用例都是为了实现这些业务用例而设计的
按照业务模块划分，或角色划分，可以分成多个图来画，并配合适当的文字简要说明

3.2. 系统用例边界

此处产出的是技术风险相关的系统用例；
一个业务可能通过多个系统的配合才可以实现，一个业务用例，可能需要多和系统用例的配合才可以实现，一个系统用例也可以在多个业务用例中被使用。

3.2.1 系统 1 用例边界

通过图形，文字描述本系统提供系统用例，一个系统用例可能是一个服务，一个外部接口，可能是系统的一个公共基础功能，对最终用户使用的系统，可能是一个页面上的操作等。

3.2.2 系统 2 用例边界

上述过程的重复

4 现有系统影响分析

描述项目对现有系统的业务造成的影响分析，这是系分工作的重要内容之一

4.1 系统 1 影响分析

分析项目对本系统的影响，例如：

• 新加的业务，功能有没有影响原有的功能
• 系统的改造对原有业务有什么影响
• 有没有影响系统对外提供的服务的约定，这非常重要

如果不明确影响，应该主动找其它系分，产品部，业务方等沟通

4.2 系统 2 影响分析

重复 4.1 节过程

5 高可用风险基线分析

该章节，对于存在高可用风险的场景，进行详细的分析和设计，用于指导高可用的风险研发工作。

5.1 风险场景一风险分析

5.1.1 风险链路分析

5.1.2 高可用风险分析

5.1.3 监控&预警分析

5.1.4 故障定位分析

5.1.5 故障应急分析

5.2 风险场景二风险分析

重复 5.1 节过程

6 资金安全风险基线分析

该章节对于存在资金安全风险的场景，进行详细的分析和设计，用于指导资金安全的风险研发工作。

6.1 风险场景一风险分析

6.1.1 资金风险描述

利用风险大盘，产出证账实风险模型；如果是已有风险场景的修改，重点描述修改点。
产出系统实现的资金流会计分录分析；如果是已有资金流修改，重点描述修改点。

6.1.2 资金风险分析

6.1.2.1 风险点列表

6.1.2.2 收费风险详细分析
**
6.1.2.3 关键核对分析
**

6.1.3 故障发现分析

按照时效性、一致性、算法类、配置类等的资金风险来源，明确故障发现方案；如果是已有业务修改，重点描述新增风险的故障发现方案。

6.1.4. 故障应急分析

从止血和恢复的角度，进行应急能力分析；主要体现在数据捞取、熔断、差错处理（应急功能 or 数据订正）等应急。

6.1.5. 风险演练分析

基于本次新增/变更的业务用例，从时效性、一致性、算法、配置等出现差错的前提下，分析故障注入方案；详细的演练方案，在项目发布计划中进行明确。

6.2 风险场景二风险分析

重复 6.1 节过程

7 变更三原则分析

基于本次新增/变更的业务用例，进行变更三原则分析，明确具体的实现方案。

brew 默认的源是 Github，会非常慢，建议换为国内的源。推荐中科大的镜像源，比较全面.
解决方案

Homebrew
Homebrew 源代码仓库

• 替换源地址:

1

cd"$(brew --repo)"git remote set-url origin https://mirrors.ustc.edu.cn/brew.git

• 重置为官方地址:

1

cd"$(brew --repo)"git remote set-url origin https://github.com/Homebrew/brew.git

Homebrew Bottles
Homebrew 预编译二进制软件包
在运行 brew, 前设置环境变量 HOMEBREW_BOTTLE_DOMAIN，值为https://mirrors.ustc.edu.cn/homebrew-bottles

• 替换源地址:
  • bash:

1

echo'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.bash_profilesource ~/.bash_profile

• zsh:

1

echo'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.zshrcsource ~/.zshrc

Homebrew Core
Homebrew 核心软件仓库

• 替换源地址:

1

cd"$(brew --repo)/Library/Taps/homebrew/homebrew-core"git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git

• 重置为官方地址:

1
2

•
cd"$(brew --repo)/Library/Taps/homebrew/homebrew-core"git remote set-url origin https://github.com/Homebrew/homebrew-core

Homebrew Cask
Homebrew cask 软件仓库，提供 macOS 应用和大型二进制文件

• 替换源地址:

1
2

cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-cask
git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-cask.git

• 重置为官方地址:

1

cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-caskgit remote set-url origin https://github.com/Homebrew/homebrew-cask

####需求：

知识竞赛从所有关卡的最好答题记录表中，获取所有关卡总分排名数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

SELECT
	t.*,
	@rownum := @rownum + 1 AS rank 
FROM
	( SELECT @rownum := 0 ) r,
	(
	SELECT
		count( a.user_id ) AS user_times,
		a.user_id,
		sum( a.score ) AS scores,
		sum( a.time_cost ) AS time_costs,
		u.nick,
		u.mobile,
		u.avatar 
	FROM
		contest_best_logs AS a
		LEFT JOIN users AS u ON a.user_id = u.id 
	WHERE
		a.act_id IN ( SELECT pass_act_id AS act_id FROM contestpro_passes AS b WHERE b.act_id = '10366' ) 
	GROUP BY
		a.user_id 
	ORDER BY
		scores DESC, time_costs ASC, user_times DESC 
	LIMIT 0,50 
	) AS t

获取的结果如下:

SELECT
    c.areaName AS province,
    d.areaName AS city,
    b.`name` AS school,
    a.NAME,
    a.department,
    a.position,
    a.telephone,
    a.mobile,
    a.reader_act_id,
    a.reader_org_id,
    ( SELECT count( c.lib_id ) FROM yuedu_creations AS c WHERE c.lib_id = a.id AND is_rec = 1 ) AS rec,
    e.title AS act_title,
    FROM_UNIXTIME( e.start_at ) AS act_start,
    FROM_UNIXTIME( e.end_at ) AS act_end,
    e.join_num as act_join_user,
    (ifnull(( SELECT sum( f.view_count ) FROM creations AS f WHERE a.reader_act_id = f.act_id ), 0) + e.view_count ) AS act_view,
    (ifnull(( SELECT count( f.id ) FROM creations AS f WHERE a.reader_act_id = f.act_id ), 0)) AS creation_count,
    ( ifnull(SELECT sum( f.like_count ) FROM creations AS f WHERE a.reader_act_id = f.act_id, 0) ) AS creation_like,
    ( ifnull(SELECT sum( f.view_count ) FROM creations AS f WHERE a.reader_act_id = f.act_id, 0) ) AS creation_view
FROM
    admins AS a
    LEFT JOIN university AS b ON a.university_id = b.id
    LEFT JOIN region AS c ON a.province_id = c.areaId
    LEFT JOIN activities AS e ON a.reader_act_id = e.id
    LEFT JOIN region AS d ON a.city_id = d.areaId 
WHERE
    a.`level` = '0' 
ORDER BY
    creation_count DESC

今天发现ecs上带宽特别大，服务器的配置是4核8G10M，按照目前的流量并不能到达目前的并发量，于是去看了一下nginx日志

每秒都有好几条数据插入，判断肯定是有人在刷点赞或者阅读量，于是搜索nginx屏蔽的方法

#!/bin/bash
tail -n 50000 /data/logs/nginx.log \   // 获取最近的50000条数据
'awk '{print $1,$7,$9}' \  // 格式化处理
'grep -i -v -E "google'yahoo'baidu'msnbot'FeedSky'sogou'360'bing'soso'403'api" \  // 排除部分爬虫的流量
'awk '{print $1}''sort'uniq -c'sort -rn \  // 根据访问量大小排序
'awk '{if($1>1000)print "deny "$2";"}' > /usr/local/nginx/conf/blockip.conf   // 插入到黑名单中

mysqlbinlog --no-defaults -v --base64-output=DECODE-ROWS --database=database -hhost -u用户名 -p --read-from-remote-server mysql-bin.000856 > test.sql