なにもしてないのに本番でエラーが出た

保守運用って大変よねっていう話。
気が向いたら読んでいってください。

前提

• 改修やリリースは一切行ってない
• 突然発生した

マジで、なにもしてないのにパソコンが壊れた感…
そうは言ってられないので、対応しました。

確認していく

エラー内容から、APIを実行しているところでエラーが起きていることが判明。
そういえば、ちょっと前に開発環境でもAPIがエラーになったのがあったなー…
APIは先方側に置いてあって、なんか変更しました？って聞いたけど、何も変更してないって言われたけども…
とりあえずcurlを叩いてみる。

[root@web ~]# curl -v --head --tlsv1.2 "https://example.com/test/v1/user" 
* About to connect() to example.com port 443 (#0)
*   Trying XX.XX.XX.XX...
* Connected to example.com (XX.XX.XX.XX) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5938 (PR_END_OF_FILE_ERROR)
* Encountered end of file
* Closing connection 0
curl: (35) Encountered end of file

開発環境で起きたのと同じエラー出てるわー…
じゃあ、開発環境と同じ対応すればよさそう。

対応

curlをアップデートして、apacheの再起動Done！

[root@web ~]# yum update curl
[root@web ~]# systemctl restart httpd.service

無事に表示されるようになりました。

まとめ

引き続き調べていったところ、
APIがおいてある先方のサーバの方で更新作業があったようで、TLS1.1以下をdropしていたとのこと。
その結果、Webサーバからのアクセスがはじかれるようになってしまっていた。
きっと開発環境でのエラーも同じ原因だったんだろう。。。

今回の学び

• 開発環境で起きたことだから、なんでだろう？を深堀りしなかったのは良くなかった
• ↑があったおかげで対応が早かったのは不幸中の幸い
• TLS1.1以下をdropするって言われてcurlに影響あるって気づけたのだろうか…たぶん無理…
• 連携する、保守するって難しい