早上回来，一看日志中心的ES集群又挂了，有2台节点离线，集群状态为red。

1、处置过程

进入各节点，查看elasticsearch进程状态，发现有两台节点的进程已挂掉。
重启es进程

[ ~]$  cd /espath
[ ~]$ ./elasticsearch -d

使用curl命令，访问可用的es节点，查看集群状态。

可以看到集群节点数已恢复，未分配的分片也在慢慢重分配中，这个时候只能等了

[ ~]$ curl -XGET "http://10.86.18.xxx:9200/_cluster/health?pretty"
{
  "cluster_name" : "elk6.4",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 5,
  "number_of_data_nodes" : 5,
  "active_primary_shards" : 21928,
  "active_shards" : 21967,
  "relocating_shards" : 0,
  "initializing_shards" : 8,
  "unassigned_shards" : 10362,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 96,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 1986814,
  "active_shards_percent_as_number" : 67.93147168877755
}

2、原因分析

curl查看各节点存储空间状态，发现各节点磁盘空间是足够的，但各节点分片数已飚到6500，大大超出了可负载能力，进而导致在集群自动定时批量创建index时进程OOM了

[ ~]$ curl -XGET "http://10.86.18.xxx:9200/_cat/allocation?v"
shards disk.indices disk.used disk.avail disk.total disk.percent host         ip           node
  6489        1.1tb     1.2tb     13.3tb     14.6tb            8 10.86.x 10.86.x 10.86.x
  6489        1.2tb     1.6tb      5.7tb      7.3tb           21 10.86.x 10.86.x 10.86.x
  1573      268.9gb     1.3tb        6tb      7.3tb           17 10.86.x 10.86.x 110.86.x
  6490        1.2tb     1.4tb      5.8tb      7.3tb           20 10.86.x 10.86.x 110.86.x
  1491      272.3gb     1.5tb      5.7tb      7.3tb           21 10.86.x 10.86.x 110.86.x
  9805                                                                                     UNASSIGNED

集群的index是通过crontab定时执行curator来删除的，查看curator日志发现在9月1日后就没再成功执行过

进一步查看crontab日志，发现根因是执行curator的appxxx用户密码过期导致

Sep  2 22:00:01 appgsvr03 crond[166761]: (appxxx) PAM ERROR (Authentication token is no longer valid; new one required)
Sep  2 22:00:01 appgsvr03 crond[166761]: (appxxx) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

3、解决方案

因之前没注意，是在appxxx用户下直接使用crontab -e配置的。现将crontab改回使用root用户执行

sudo vi /etc/crontab

# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
00 22 * * * root curator --config /curator/curator.yml /curator/action.yml

【问题现象】
使用ubuntu的软件更新器进行安全更新时，提示错误如下。直接使用apt-get insall软件也出现同类提示

检查您是否使用了第三方源。如果是就禁用它们，它们常常导致问题。
然后在终端中运行以下命令：apt-get install -f
Transaction failed: 软件包系统已损坏
 下列软件包未满足的依赖关系：

libc6-dbg: Depends: libc6 (= 2.31-0ubuntu9.2) 但是 2.31-0ubuntu9.1 已经安装
libc6-dev: Depends: libc6 (= 2.31-0ubuntu9.2) 但是 2.31-0ubuntu9.1 已经安装
           Depends: libc-dev-bin (= 2.31-0ubuntu9.2) 但是 2.31-0ubuntu9.2 已经安装

【处理过程】
根据提示，运行apt-get install -f尝试修复安装

[ubuntu ~]$ sudo apt-get install -f
debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
dpkg: 处理归档 /var/cache/apt/archives/libc6_2.31-0ubuntu9.2_amd64.deb (--unpack
)时出错：
 新的 libc6:amd64 软件包 pre-installation 脚本 子进程返回错误状态 1
在处理时有错误发生：
 /var/cache/apt/archives/libc6_2.31-0ubuntu9.2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


下列软件包有未满足的依赖关系：
 libc6-dbg : 依赖: libc6 (= 2.31-0ubuntu9.2) 但是 2.31-0ubuntu9.1 已经安装
 libc6-dev : 依赖: libc6 (= 2.31-0ubuntu9.2) 但是 2.31-0ubuntu9.1 已经安装

先行尝试使用 dpkg -i -force-overwrite 安装指定的包，发现也提示同样错误

[ubuntu ~]$ dpkg -i -force-overwrite /var/cache/apt/archives/libc6_2.31-0ubuntu9.2_amd64.deb

debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
dpkg: 处理归档 /var/cache/apt/archives/libc6_2.31-0ubuntu9.2_amd64.deb (--unpack
)时出错：
 新的 libc6:amd64 软件包 pre-installation 脚本 子进程返回错误状态 1
在处理时有错误发生：
 /var/cache/apt/archives/libc6_2.31-0ubuntu9.2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

这时，注意到这一句：debconf: DbDriver “config”: /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable。表示文件被其他进程锁死，才会无法继续进行安装。

那就尝试找出这进程并kill掉，释放文件占用锁死。

[ubuntu ~]$ lsof /var/cache/debconf/config.dat #会显示打开此文件的进程和PID
[ubuntu ~]$ kill -9 PID  #强制杀掉进程

但结果无法结束进程。。。

【最终解决方法】
删除/var/cache/debconf/下的所有dat文件，然后update软件源，再次运行更新安装恢复正常

[ubuntu ~]$ sudo rm -rf /var/cache/debconf/*.dat
[ubuntu ~]$ sudo apt-get update
[ubuntu ~]$ sudo apt-get install -f

7月，收益达19%。主要是神操作逃过了7月16日的大跌，在7月24日再跌又是相对轻仓。至于，为什么会有7月15日全清仓神操作，总结起来是客观分析+理智心态+少少运气。客观分析是一直认为股市与经济面背离太严重，肯定会一个大回调。再加上观察一个现象：一些从来没有接触过股票的人群，也在热烈讨论并且冲刺入市。理智心态是控制着了自己贪婪心态，再加上一点点运气，促成了7月15日全清仓操作。

在7月下半月操作中，还是犯了错误，没有遵守之前分析选中的板块。错过了医药疫苗板块（达安基因、丽珠集团）。而且在逃过大跌后，心态上有点患得患失，操作节奏也受到影响。而且临时更换标的，反复短线操作过证券、生物和白酒。长远而言，这样的操作方式并无好处，很容易跌入追涨杀跌。

还是应该通过阅读经典投资书籍，总结、提炼出属于自己的投资决策模型，并且进行实践，根据实践结果再进行模型调整，敏捷、迭代，最终成就自我。

一、背景

与同事在通过容器云平台（公司采购的某国内商业产品）部署某系统平台时，同事对文件做了修改并重新构建镜像但没有更改Tag。部署应用时，发现没有起效，一开始以为是容器云平台的Bug，后来感觉有可能是Kubernetes的问题，因此动手进行了验证。

二、原因分析

初步粗略判断，出问题的地方可能有：

• 1、镜像没上传成功，或者镜像仓库有问题
• 2、容器云平台的问题
• 3、kubernetes自身的镜像更新判断机制

通过查看、对比镜像 Image ID，确认镜像上传和镜像仓库均没问题。

与供应商沟通，确认若容器云平台前端界面进行修改，则相当于更新yaml文件给Kubernetes执行，中间并没有再加工处理。而同事除了更新镜像内容，还修改过启动命令，因此容器云平台也没有问题。且通过在Kubernetes集群导出应用的yaml文件，确认使用的镜像拉取策略为imagePullPolicy: IfNotPresent，即本地若有镜像则不会重新拉取。

那最后就是Kubernetes自身的镜像更新判断机制了，这个可以通过动手实验来验证下。

三、实践验证

验证思路：构建Nginx镜像，创建Pod并定义imagepullpolicy：ifNotPresent，通过修改index.html内容，来分别实现【重新构建镜像内容但不更改Tag】和【重新构建镜像内容且更改Tag】，进行验证。

1. 编辑Dockersfile。主要是使用Nginx做为基础镜像，复制一个网页文件进去重新构建验证镜像。

   [root@masterserver imagepullpolicy]# vi Dockerfile
   FROM harbor.xxx.com.cn/library/nginx:1.13.8-alpine
   COPY index.html /usr/share/nginx/html/

2. Docker Build构建镜像

   [root@masterserver imagepullpolicy]# docker build -t mynginx:1.1 .
   Sending build context to Docker daemon  4.096kB
   Step 1/2 : FROM harbor.xxx.com.cn/library/nginx:1.13.8-alpine
   ---> bb00c21b4edf
   Step 2/2 : COPY index.html /usr/share/nginx/html/
   ---> be86871a6bce
   Successfully built be86871a6bce
   Successfully tagged mynginx:1.1

3. 使用kubectl run –dry-run且带上imagepullpolicy参数，输出yaml文件。

   [root@masterserver imagepullpolicy]# kubectl run testnginx --image=mynginx:1.1 --dry-run=client --image-pull-policy=IfNotPresent -o yaml > testnginx.yaml
   [root@masterserver imagepullpolicy]# cat testnginx.yaml 
   apiVersion: v1
   kind: Pod
   metadata:
   creationTimestamp: null
   labels:
   run: testnginx
   name: testnginx
   spec:
   containers:
   - image: mynginx:1.1
   imagePullPolicy: IfNotPresent
   name: testnginx
   resources: {}
   dnsPolicy: ClusterFirst
   restartPolicy: Always
   status: {}

4. 通过kubectl apply -f nginx.yaml，运行pod。
5. 修改index.html内容，重新构建镜像但不修改tag，再重新kubectl apply。查看pod事件

   [root@masterserver imagepullpolicy]# kubectl describe po mynginx
   Name:         mynginx
   Namespace:    default
   Priority:     0
   Node:         node1/192.168.56.104
   Start Time:   Wed, 05 Aug 2020 11:02:41 +0800
   Labels:       run=mynginx
   Annotations:  Status:  Running
   IP:           10.244.1.12
   IPs:
   IP:  10.244.1.12
   Containers:
   mynginx:
   Container ID:   docker://6aebe0a359144afa5cd9da4e04d8837e62d7c26118b64933d4b71af50cab07f2
   Image:          harbor.xxx.com.cn/test_dmgtest/mynginx:1.1
   Image ID:       docker-pullable://harbor.xxx.com.cn/test_dmgtest/mynginx@sha256:09a2064d81e1ffbb9c126320d5a3c1173585969da9160e26559bbb777ba2ed4d
   Port:           <none>
   Host Port:      <none>
   State:          Running
     Started:      Wed, 05 Aug 2020 11:04:07 +0800
   Ready:          True
   Restart Count:  0
   Environment:    <none>
   Mounts:
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-768sh (ro)
   Conditions:
   Type              Status
   Initialized       True 
   Ready             True 
   ContainersReady   True 
   PodScheduled      True 
   Volumes:
   default-token-768sh:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  default-token-768sh
   Optional:    false
   QoS Class:       BestEffort
   Node-Selectors:  <none>
   Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                node.kubernetes.io/unreachable:NoExecute for 300s
   Events:
   Type     Reason     Age                From               Message
   ----     ------     ----               ----               -------
   Normal   Scheduled  <unknown>          default-scheduler  Successfully assigned default/mynginx to node1
   Normal   Pulling    34s (x3 over 78s)  kubelet, node1     Pulling image "harbor.infinitus.com.cn/test_dmgtest/mynginx:1.1"
   Normal   Pulled     <invalid>          kubelet, node1     Container image "harbor.xxx.com.cn/test_dmgtest/mynginx:1.1" already present on machine 
   Normal   Created    <invalid>          kubelet, node1     Created container mynginx
   Normal   Started    <invalid>          kubelet, node1     Started container mynginx

在pod事件中，可以看到 【Container image "harbor.xxx.com.cn/test_dmgtest/mynginx:1.1" already present on machine 】。

而通过Docker images，可以查看image id是两个不同的id。

四、结论

通过实践验证，可以得出结论：当pod定义了imagepullpolicy: IfNotPresent，判断运行pod的node本地有没有镜像。进一步，这个判断机制Kubernetes原生是这样设置的：会根据tag来判断，而不是根据sha id来判断。
所以即使镜像内容变化重新构建镜像但Tag没有更改的话，kubernetes是不会去重新拉取镜像的。

一、红红火火的6月

6月收益率14%，虽然跑输创业板指，但远远跑上证。看来后面可以需要开通创业板和科创板了，挑战一下。

二、交易操作回顾

按此前策略，6月新入浪潮信息（且趁低补仓）、五粮液、三全食品。清仓的有三全食品、三安光电、三七互娱和和而泰，好像对三字头情有独钟！

• 和而泰收益不太理想，持仓71天，扛过了3月大跌，终于在5、6月回调了回来。操作是正确的，卖出换仓。
• 三全食品持有12天，小赚3个点就出了，都不太记得为什么要出掉，又违反长持股原则纪律，后续要注意改进。
• 三安光电，清仓两次，成功抓住了两个波段，感觉不错。
• 五粮液是放弃水井坊后入的白酒股，走势稳健，不错。就是可惜入得少，一直在慢涨、价位较高，有点不太敢入。手上还持有消费ETF，也相当于白酒股了，就不追了。
• 6月最后2天，在早市阶段，浪潮低开3个点时小量补仓，虽然违反了原则，但原因是当时感觉当天会回调，结果当天浪潮跌到7个点，继续再大量补仓。目前是重仓浪潮信息，押注IDC基础设施。

整体看，6月操作还是挺成功的，都是对前期选定的交易标的进行操作，这种策略需要继续保持。

三、7月怎么走？

1. 疫情方面，国内还在严防，国外还在反复。疫情已持续半年，全球各个经济市场也已适应，因此感觉对股市冲击应该不会再有像2、3月的“黑天鹅”事件出现。可以继续关注基因、疫苗和医药股票。
2. 由此延伸，游戏、食品和饮料，还是相对看好，没得出去浪要呆在家，娱乐和吃喝是必需的。如果开通了创业、科创，可以关注下新上的线上办公股票，带科技属性。另外，5G、IDC建设、云计算这些新基建方面，也可以继续关注，这些都国家拉动经济重点投资的方向。
3. 至于经济下滑，对民生、社会的冲击，到目前还没出现此前自己担心的失业潮、“恶性事件”增多情况，感觉中国社会韧性还挺强的。但还需继续保持警惕和理性，不能太过盲目乐观。
4. 中国和周边国家，还有美国的摩擦与贸易战，感觉也一时半会应该不会突然恶化。背后都是为了利益，成了你来我回的持久战。特别是特朗普受“黑人平权事件”影响，目前连任形势有些不明朗，理论上应该不会与中国撕破脸皮恶战。至于中国与印度的边境摩擦，继续观望就好，两方应该都不会发起“热战”，毕竟一开火就是烧钱，双方都不太烧得起。
5. 世界各国还在继续放水刺激经济，银行的信用贷、抵押贷，听说利率降到了4%左右，资质好的还可以再低点。可见，钱多了起来，不是流进股市就是房市，7月感觉还会是收益不错。
6. 需要防范的是钱多就会吹起泡沫，也就是说在选股时更应识别有投资价值的价值股，切不能追热点、追概念。同时时刻控制好仓位，保持理性，切忌贪婪。

一、以赚少5%收益教训自己坚持原则和纪律

上周四晚美股大跌，周五早上决定视情况将三七互娱出掉，锁定已有收益。策略是没错，但违反了自己定下的交易纪律，选择在竞价交易时下单全部出掉，没有去观望开市情况，最终结果是赚少5%。

三七互娱是在上周五最低位出掉的，痛哭无泪。。。

二、振作再战吧！市场永远充满机会和风险

周末两天，主要消息是：

• 北京爆发小范围疫情，在进口三文鱼切割案板上发现病毒。
• 创业板改革措施快速落地。
• 另，早上看到新闻说昨晚美的创始人何享健被劫持，警方已抓获5名罪犯，事主安全。但直觉觉得事发原因应该与当前经济下滑下关，总感觉经济下滑对社会安定的负面影响在逐步加大。
• 国外疫情还没完全控制，上周四、周五相关概念股也已经涨了一波。

这周操作思路，今、明天观望为主，除非投资标的大跌7%或以上才趁低吸纳，即使涨停也应保持心态平稳。
潜在标的加上医疗：鱼跃医疗、丽珠医药，再继续观望三七互娱、美亚光电、五粮液。

一、转为投资策略，以中长线为主，多点耐心，少操作

这两周，都主要忙于工作，没太多时间分析行情和盯盘。因此，后续投资策略转换为中长线为主，平均持仓时间应该以月为单位计算。给多点耐性，有时间就只做做基本面、大趋势的分析和洞察，给多点耐性，少操作少折腾，特别是严禁追热点、炒短线。

另，从之前长期跟踪的美亚光电、水井坊近半年走势来看。其实自己已在基本面、公司经营情况、市场趋势等维度综合评估，认定为“价值投资标的”的话，长期持有（半年或一年以上）的收益都不会太差。特别是美亚光电，18年开始跟踪快2年多，竟然没能坚定持有，简直有点想抽自己耳光。

二、上两周回顾和后续思路

• 回顾5月，没能继续4月的凌厉势头，总收益亏损-0.89%。虽没严重亏损，但其实在5月第3周若做到坚决获利离场的话，收益应该为正才对。也正因此，才有上文的投资策略转换决定。
  
• 按之前策略，在5月进了三安光电（5G方向+消费电子）、三七互娱（游戏），上周6月初进了浪潮信息（IDC基础建设）。
  在今天，在三安光电高位，获利近10个点出清后，也是按之前策略再进了三全食品（食品股）。
  
  

  三、具体持仓股票和操作

  目前仓位8成，持有消费ETF、三七互娱、浪潮信息、三全食品、和而泰。分别对应大消费基金、游戏娱乐、IDC基础建设、食品和消费电子+北斗，再加上白酒股次龙头五粮液做为潜在标的，这个组合在市场趋势上应该是比较稳健的。
  后续视个股走势，进行相应仓位控制的交易即可。另外，密切关注五粮液走势，若出现较大幅度回调可以进入。

一、牛人的一生，就是开挂的一生

苏世民，维基百科是这样介绍的：

史蒂芬·艾伦·施瓦茨曼（英语：Stephen A. Schwarzman，1947年2月14日－）或译作苏世民，美国大亨与金融家，与前美国商务部部长彼得·乔治·彼得森在1985年成立全球著名私募股权与管理咨询公司黑石集团。根据《福布斯》统计，施瓦茨曼个人财富达108亿美元^[3]。 截至2014年，《福布斯》亿万富翁排行榜上位列122位^[4]。在2019年美国400富豪榜，他以177亿美元的资产，排名第29名^[5]。

维基百科

本科就读于耶鲁大学毕业，硕士毕业于哈佛商学院，在学校已展露出他的非凡领导力。毕业后加入雷曼兄弟，31岁就做到总经理职务。而后创建了黑石集团，成为全球著名的私募股权基金和并购业务公司。

出生在美国中产阶级家庭，就读名校，成名于华尔街。创立黑石集团后，其业务与全球各国政要名流均有联系。看似开挂的人生，其实背后有着他的勇气、坚毅和智慧。

二、 他的经验与教训

…人们最感兴趣的话题永远是“自己的问题”。如果你能发现对方的问题所在，并提出解决方案，那么他们一家愿意跟你沟通，无论他们的等级或地位如何。问题越困难，解决方案越少，你的建议就越有价值。为人人避之不及的问题提供解决方案，才是竞争最小、机会最大的领域…

《苏世民：我的经验和教训》

这就要求自己能做到真正的倾听，换位思考，从对方角度思考问题，才能做到为对方提供真正有价值的解决方案或建议。帮助他人，为他人提供价值的同时，即是展现和积累了你自身价值。

…把时间和精力投入自己热爱的事物上。热情所至，卓越必成，单纯为了他人的敬仰和尊重而做事，则很少能带来成功。如果你对追求梦想充满热情，如果你能勇往直前，如果你以帮助他人为已任，你的人生就会充实而有意义，你也永远有机会建功立业、成就不凡。你为他人付出的善意和努力，最终会给你自己、你所爱的人以及整个社会带来福报。…

《苏世民：我的经验和教训》

这是西方哲学和宗教典型的“奉献、博爱、利他”思想，通过利他的同时也是达就利己。换成管理学语言，即是愿景、自驱力、个人价值实现。这需要个人有远大的理想追求、坚定的价值观和坚毅的品质。感觉，这也是当今中国社会缺乏的，也是我自己所缺乏的。

…任何投资的成功与否在很大程度上取决于所处经济周期的节点。周期会对企业的成长轨迹、估值及潜在回报率造成重大影响。…

…市场触顶的指标是身边赚到大钱的人数。声称表现优异的投资者数量随市场的超市而增长。…

《苏世民：我的经验和教训》

如何判断市场到顶，简单来说：就是人人都可以从投资市场中赚到钱。就是通街的人都在谈论股票、期货、货币政策等等。当前，感觉还处在“市场恐慌”末段，加上当今世界的不确定性因素太多且传导更快、关联性更强，经济周期走势更加难以估计。

三、总结自己的经验和教训

书中，苏世民总结的经验和教训还有许多，可能是个人阅历不够，很多内容并没有太大共鸣。

借鉴别人经验，可以让自己少走弯路。但我认为最重要的还是，要不断总结自己的经验和教训，不断提升自我，方能实现个人价值。

1、学习Markdown

这是正文，开始学习Markdown
一级标题的Markdown语法是：#空格 内容

1.1 测试二级标题

这是二级标题正文
二级标题的Markdown语法是：##空格 内容，以此类推

• 列表一
• 列表二

列表的Markdown语法是：- 内容

三级标题

插入图片，效果如下

Markdown语法：![]（ 图片地址）

2、二级标题

插入代码块
improt ing
what 's up
##注释，说明

插入代码块的Markdown语法是：用撇号 ` 开始和结束

一、上周五大跌，但周末也没有什么坏消息

5月22日，国内股市普跌，我的自选股回调3-5个点。这个跌法，可以说是有点出乎市场意料。主要原因是两会没有较强烈刺激政策出来，而且没有制定今年GDP目标，再加上对HK在安全方面的立法和美国对此的表态，港股下跌带累了A股。

本周末两天，除了美国商务部新增国内33间公司进入“实体名单”外，整体没有什么坏消息。至于香港的“动静”，都已经闹了一年了，市场也已经习惯了。
国外疫情还在慢慢发展，但出没有新爆发点，疫苗国内科学家陈薇在全球顶级医学期刊《柳叶刀》发表论文，前期人体试验疫苗产生重大进展。估计周一基因生物板块应该会跟涨。

二、在工作较忙，没时间盯盘情况下，还是应该严格执行自己前期写下的策略

上周二定下策略是趁高点将三安光电出掉，结果周三时还是贪心，挂了一张价位较高的单，最终没成交。

四川路桥亏损5.2%，买个教训（幸好入得不多），后面对于追热点真的要慎重。这个倒是坚持了策略，在周五就算低位也出清了。

看来自己还是难以战胜人性，“贪利怕死”，盈利时想赚更多就挂高价位单没走掉。亏损时怕亏更多，下跌也走，若周一反弹千万别后悔、懊恼！

最近工作都比较忙，没时间紧盯大盘的情况下，还是要做到严格遵守自己的策略，控制“欲望”、严守交易纪律。

二、下周操作思路

上周，都在回调时补仓了三安光电、三七互娱，目前持仓是再加上消费ETF、和尔泰，目前仓位已达85%。整体思路还是减少操作、先持有观望吧，5月余下这周时间估计还是会保持震荡行情。

感觉周一大市大概率会微涨，但若回调甚至是暴跌，看是否要降低部分仓位，也要做好心理准备。