RabbitMQ 删除队列

项目中使用到了RabbitMQ，使用了大量的一次性队列，然而没有设置自动过期、自动删除等特性。长期运行导致了大量的队列产生，非常影响性能及问题排查效率。这里收集了一些可以批量删除队列的方法，供参考。

方法一：设置过期策略

优点：操作简单，可针对有规律的队列进行策略设置
缺点：想不到有什么缺点

# 设置规则
rabbitmqctl set_policy delete_gen "amq.gen-.*" '{"expires":1}' --apply-to queues

# 取消规则
rabbitmqctl clear_policy delete_gen

# 如果要作用于所有队列
rabbitmqctl set_policy delete_all ".*" '{"expires":1}' --apply-to queues

方法二：重置数据库

优点：简单，删除全部队列
缺点：粗暴

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app

方法三：删除vhost

优点：删除一个vhost的所有队列，包括Exchange
缺点：仅适用需要删除一个vhost的场景

curl -i -XDELETE http://USERNAME:PASSWORD@127.0.0.1:15672/api/vhosts/VHOST_NAME
# 例子
curl -i -XDELETE http://admin:123456@127.0.0.1:15672/api/vhosts/%2F

方法四：通过HTTP API删除

优点：HTTP API灵活
缺点：一次删一个

curl -i -XDELETE http://USERNAME:PASSWORD@HOST:PORT/api/queues/VHOST/QUEUE_NAME
# 例子：
curl -i -XDELETE http://admin:123456@127.0.0.1:15672/api/queues/%2F/test_queue

方法五：使用rabbitmqadmin工具

优点：使用方便
缺点：底层也是使用HTTP API实现的

rabbitmqadmin --host=HOST --port=15672 --ssl --vhost=VHOST --username=USERNAME --password=PASSWORD delete queue name=QUEUE_NAME

haproxy http 重定向 https

对于http端口：80，https端口：443

frontend app
    bind *:80
    bind :443 ssl crt /etc/haproxy/server.pem no-sslv3
    mode http
    option httplog
    option forwardfor
    rspidel ^Server.*
    redirect scheme https if !{ ssl_fc }
    default_backend app

backend app
    mode http
    option httpchk HEAD /
    server app01 server1:3000 check inter 2000 rise 2 fall 5

对于http、https端口不为80、443时，以上的方法就行不通了，得使用下面的方法

frontend app
    bind *:8080
    bind :8443 ssl crt /etc/haproxy/server.pem no-sslv3
    mode http
    option httplog
    option forwardfor
    rspidel ^Server.*
    http-request redirect code 301 location https://www.haxi.cc:8443%[capture.req.uri] if !{ ssl_fc }
    default_backend app

backend app
    mode http
    option httpchk HEAD /
    server app01 server1:3000 check inter 2000 rise 2 fall 5

故障管理流程 Incident Management

  1. 目标

    在短时间内恢复服务正常运营（满足 SLA [Service-Level Agreement]），将业务运营的负面影响降至最低。

  2. 范围

    包括：

    • 用户和技术人员报告的失效、问题或疑问
    • 事件监控工具的自动发现和报告

  3. 对企业的价值

    • 能够检测和解决故障
    • 能够将IT活动与实时业务优先级相关联
    • 能够发现潜在的服务改进方面
    • 服务台可以从中发现额外需要的服务或培训需求
    • 故障管理在企业中有很高的曝光率，更容易展示出流程价值所在，为争取投资提供支持。

  4. 基本概念

    • 处理时限：

      • 根据 SLA 中规定的整体故障响应与解决目标，在不同的故障处理阶段必须确定具体处理时限。要在 OLA [Operational Level Agreement] 和 UC [Underpinning Contract] 中作为目标明确规定
      • 所有支持小组必须清除了解这些处理时限
      • 可以借助服务管理工具用于自动执行处理时限，并根据预定义规则升级

    • 故障模型：

      • 预定的“标准”故障模型将有助于在故障发生时对应到合适的故障
      • 按故障模型要求将信息输入到故障处理支持工具中，之后该类工具可以自动进行流程的处理、管理与升级工作

    • 模型包括：

      • 处理故障应遵循的步骤
      • 这些步骤应遵循的时间顺序，相互依赖关系
      • 职责
      • 措施完成的时间表与阈值
      • 升级程序，应该联系谁，何时进行升级
      • 任何必要的证据保留

    • 重大故障：

      • 组织必须明确标识出哪类事件构成重大故障
      • 必要时可以动态成立一支重大故障处理团队
      • 如果需要调查故障原因，问题经理也需要参与其中
      • 服务台需确保所有活动均记录在案，且用户了解具体进展

生产环境权限管理项目方案

1 问题现状

1.1 员工使用root权限操作生产环境

当前我们公司内部服务器实例有上百台，管理客户的服务器也将近有上百个服务器示例。各个服务器上的管理人员很多（开发、运维、项目、工程人员等），在大家登录使用Linux服务器时，不同职能的员工对Linux系统的熟悉程度不同，因此导致操作很不规范，root权限泛滥（几乎所有员工都使用root权限操作），经常导致文件等莫名其妙的丢失，服务器文件、目录权限混乱等问题。这样使得公司内部、客户服务器安全存在很大的不稳定性、及操作安全隐患。据调查企业服务器环境，50%以上的安全问题都来源于内部，而不是外部。为了解决以上问题，单个用户管理权限过大现状，现提出针对Linux服务器用户权限集中管理的解决方案。

1.2 操作记录不可追溯

当前我们公司管理着几大平台和数十个小平台。我们的客服、工程、研发人员都是直接连接SSH的，其中的操作不可过滤、不可审计、不可追溯。如果出现了操作失误，将无法追溯，不知道是谁操作的，不知道什么时候操作的，不知道操作了什么。

1.3 程序使用root权限运行

所有自主程序和部分第三方开源程序（如redis）都使用root权限来运行，使用root权限存在非常大的安全隐患。比如：

1) 程序原本的功能是想删除自身的日志文件，如果程序有BUG，拼接路径时考虑不周全，可能会导致误删了系统文件。严重时可导致系统奔溃，数据丢失。

2) 程序使用了开源框架有远程执行命令的安全漏洞，那么黑客可能会获得系统的root权限，既可为所欲为，公司、客户数据安全则面临着巨大的威胁。

3) redis的弱密码、空密码存在很大的安全隐患，如使用root运行redis，黑客很容易就拿下操作系统的root权限。

图解 LVS

LVS 基础架构拓扑

LVS基础拓扑.png