既存のZabbixサーバが最新OSに対応できなくなってきたので最新のZabbixサーバへのリプレイスを推進。
併せてAPMもCactiからより使い勝手の良いPrometheus+Grafanaへリプレイスを実施。

・メンバーに対する作業指示、進捗管理
・既存の監視システムの監視ポイント、モニタリングの方針について共有

新しいOSの監視に対応することができ監視環境の整備が進みました。
またCactiからPrometheus+Grafanaへのリプレイスにより、モニタリング対象の追加/削除に関わる作業コストを削減し、グラフの表示がよりスムーズに確認できるようになりました。

AWS Aurora(MySQL 5.7)のEOLに伴い、ECカート・CRMシステムで利用しているDBをAurora(MySQL 8)にリプレイス。
NHN Cloudとオンプレ環境で動いているMySQLサーバも併せてMySQL 8 にリプレイスを実施。
リプレイス環境の設計・構築・調整・リプレイスまで一貫して担当。

・リプレイス手順の調査、検証
・MySQLのパラメータ精査、差異調査
・テスト環境のリプレイス実施、ログ/エラーが出ていないか確認
・作業日時(システム停止)に関しての社内調整
・本番環境のリプレイス実施、ログ/エラーが出ていないか確認

対象のDBサーバが多かったのでメンバーと分担して深夜(早朝)に作業を実施。
特に障害や問い合わせが発生することなく無事リプレイスを完了しました。

CRMシステムのインフラに関するコストを下げられないか？という要望が上長から届いたので対応

・現状のリソース使用状況の調査
・発生しているCPU負荷について開発側と協力して調査
・コスト削減方法について提案
・OS選定
・コスト削減を実現するためのサーバ環境の構築
・既存環境からコンテナ環境へのリプレイス手順の検証
・既存環境からコンテナ環境へのリプレイス実施

4vCPUではリソースがやや過剰、しかし2vCPUではリソース不足という状態でしたので、CRMシステムをLXCコンテナ化を実施。
より多くのCPUを搭載したサーバに複数のLXCコンテナ(CRMシステム)を動かせるようになり、サーバコストを削減しました。

CRMシステムのサブシステムととなるデータ分析環境を新規に構築。
(LTV・RFMなどのデータ集計を行い、CRMシステム上で確認できる機能)

・開発側と要件定義、仕様擦り合わせ
・テスト環境の構築
・本番環境の構築
・開発側と監視ポイントについて調整

データ分析システムのリリースを無事完了。
死活監視・性能モニタリングによりリリース後に発生した過負荷状態も即時検知し開発側に改修を依頼するなど滞りなく利用できる状態に運用。

開発中のCRMシステムをそろそろ本番環境にリリースして利用できるようにしたいということで、AWS上に新しくテスト環境と本番環境を構築。

・開発環境のシステム構成調査
・開発側と要件定義、仕様擦り合わせ
・テスト環境の構築
・開発(テスター)に構築した環境での動作確認を依頼
・本番環境の構築

EC2インスタンスとして環境の構築を完了。
AMIイメージを作成し、今後のサーバ追加を半自動的に実施できる状態に整備。

ECシステムのOS/PHPが古くセキュリティ的観点からOS/PHPのアップグレード(リプレイス)を実施。

・既存のWeb/アプリケーションサーバの構成調査
・OS選定
・開発側と要件定義、仕様擦り合わせ
・テスト環境の構築
・開発(テスター)に構築した環境での動作確認を依頼
・本番環境の構築
・既存環境から新環境へのリプレイス手順の検証
・既存環境から新環境へのリプレイス実施

お客様環境毎にリプレイスを実施。
特に障害や問い合わせが発生することなく無事リプレイスを完了しました。

入社した直後で監視やモニタリングツールも動いていない状態でしたので、システム構成を理解するとともに、稼働状況を把握するための監視システム(死活/性能)を導入し、障害時に検知・対応できる体制を構築しました。

・ECカートのシステム構成の調査
・Zabbixサーバの構築
・Cactiサーバの構築
・対象サーバにZabbixエージェント、snmpdなどのインストール
・Cacti上でグラフの生成
・Zabbixの監視、通知設定

ECカートシステムで利用しているサーバをグラフとしてモニタリング、死活監視できる状態を整備しました。
また、関連するSSL証明書とドメインを台帳にまとめるととともにチェックフローを用意し更新漏れを防ぐ体制も整えました。

QAコミュニティで利用しているファイル(NFS)サーバとDB(MySQL)サーバのハードウェアが老朽化し保守も切れている状態のためリプレイスを実施。

・物理サーバの選定、購入
・ファイルサーバの冗長化方式の調査、検証
・DBサーバの冗長化方式の調査、検証
・テスト環境の構築
・本番環境の構築

長時間稼働させた場合にCorosync(Pacemaker)が正しく相互にノードが認識されないような状態が見つかったため、ファイルサーバはGlusterFS、MySQLはMasterHAを利用する方針を提案しました。

利用しているHadoopのバージョンがEOLになるということでバージョンアップを実施。

・バージョンアップ手順についてベンダに問い合わせ
・CloudereManagerの導入手順についてベンダに問い合わせ
・検証環境の構築
・CloudereManagerの導入手順の検証
・バージョンアップ手順の検証
・本番環境にCloudereManager導入
・本番環境のバージョンアップを実施

Hadoopのバージョンアップを無事完了。
バージョンアップに併せてCloudereManagerを導入することで、他メンバーでもGUI画面から簡単に運用できる環境を整備しました。

通信遅延や応答エラーが発生した場合に原因特定を迅速化できることを目的として、オンプレミス環境のネットワーク全体のリクエスト/トラフィックをグラフとして確認できるようツールを開発/整備。

・NetScalerが取得できるメトリクスの調査
・メトリクスを取得、保存するツールの開発
・グラフとして表示する機能の開発

ネットワーク全体の傾向を俯瞰することができ、障害発生時の初動としてNW機器/サーバに個別にログインしてログを確認する煩雑な障害対応を効率化しました。

NetScreenで利用しているOSがEOLになるということでバージョンアップを実施。

・バージョンアップ手順についてベンダに問い合わせ
・検証項目の洗い出し
・検証環境の構築
・バージョンアップ手順の検証
・本番環境のバージョンアップ実施

検証環境で入念に手順と影響範囲を確認できたことで、本番環境のバージョンアップも数秒の断が発生するのみでWebサービスへの影響を最小限に留め無時完了しました。

各Webサービスで必要とされるNASストレージの設計～運用まで一貫して対応。

・各サービス担当者から要件をヒアリング
・要件に応じたNASストレージの設計、見積もり取得
・サービス担当者と擦り合わせ、発注
・NASストレージの設置、配線などを各データセンターの業務委託に依頼

障害レベルに応じた一次対応とエスカレーション手順を各データセンターに配置された業務委託に展開し、著しくサービスに影響が出るような重大障害以外は業務委託と保守ベンダ間で完結可能なフローも整備。

発売前のサーバをベンダからレンタルして、Webサービスで今後利用できる標準的なサーバとしての検証・選定を行う。

・検証項目のリストアップ
・検証項目の実施
・負荷テストの実施
・物理的な要件の確認を各データセンターの業務委託に依頼

検証結果や要望をベンダと共有することで製品の改善や自社にメリットのある製品開発に貢献。

依頼ベースで人手で各サーバにアカウントを設定している状況であり、それを自動的にデータベースと連携してサーバのアカウントとして反映・管理するツールの開発・導入。

・アカウント管理ツールの調査、テスト
・サーバ管理ツール(サーバのデータベース)担当者とのAPI連携の調整
・開発環境にアカウント管理ツールの導入
・本番環境にアカウント管理ツールの導入

サーバに関する各種情報(担当者や部門など)が格納されたDBと連携しサーバへのアカウント適用を自動化し、それに消費されていた1人日程度のリソースを解放。

FreeBSDサーバに関してはハードディスク故障時に自動的に検知・交換する仕組みが整っていたが、Linuxサーバについては未整備の状態だったため、同じ様な方式で自動的にハードディスクの故障を検知・交換する仕組みを整備する。

・既存のFreeBSDサーバの仕組みの調査
・Linux向けのハードディスク故障を検知する仕組みの調査、検証
・Linuxサーバへのツールのインストール
・検知した場合の交換フローをデータセンターの業務委託に共有

ツールからの通知を基に業務委託だけで完結するディスク交換フローを導入し、担当部門→運用部→業務委託と依頼ベースの人手によるフローを排除。