A Day In The Boy's Life -53ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

logrotateの設定を変更してしばらく運用していたら、本来保存したい世代数とは異なって動いていることに気がつきました。

設定を見直しても正しいように見えて結構はまったのでメモしておきます。



logrotateの個々の設定ファイル内の定義場所に注意


答えは、logrotate.dの下に保存する個々のログファイルの設定の記述方法に誤りがありました。

デフォルトのlogrotateの設定は、/etc/logrotate.confに以下のような感じで書いていきます。


# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 8

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
compress

この設定は、特定のログファイルに適用するのではなく、logrotate全体の設定になっています。

これらの設定を変更したい場合は、logrotate.d以下の個々のログファイルの中で設定を上書きしていきます。


/var/log/httpd/*log {
    daily
    missingok
    notifempty
    sharedscripts
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
}


上記の場合、毎週のログのローテーション(weekly)が、毎日(daily)となります。

記述する位置は、ローテーションさせたいログファイルのパスを{ }で囲みその中に書いていくのですが、うっかりその外に書いてしまうと、その他のログファイルへも適用されてしまいます。(構文エラーにはなりません)


daily
missingok
notifempty

/var/log/httpd/*log {
    sharedscripts
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
}


上記のように書くと、httpdの設定ファイルが読込まれた以降のログファイルにおいて、ログローテーションのタイミング(daily)や、該当のログファイルがなかった場合でもローテーションしたり(missingok)、ログファイルが空の場合はローテーションしない(notifempty)設定で動いてしまいます。


ログローテーションの設定ファイルの読み込み順は、アルファベット順のようです。

実際の設定ファイルの読み込み順を確認してみたい場合は、テストで実行してみるとわかります。


# logrotate -d /etc/logrotate.conf
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file acpid
reading config info for /var/log/acpid
reading config file apps
reading config info for /var/log/php.log
reading config info for /var/log/conman/*
olddir is now /var/log/conman.old/
reading config file cups
reading config info for /var/log/cups/*_log
reading config file httpd
reading config info for /var/log/httpd/*log
reading config file iscsiuiolog
reading config info for /var/log/iscsiuio.log
reading config file mgetty


先ほどの誤ったhttpdの設定ファイルの例をそのままにしておくと、それ以降に読込まれているiscsiuiologなどのログファイルが本来の設定とは違った動きをしてきます。

私の環境では、設定ファイルがaから始まるものであったため、それ以降全てのログファイルに影響を与えていました・・・。


実際にログがどのように動いているかは、やはりテストで実行してみればわかります。


# logrotate -d /etc/logrotate.conf
- snip -
rotating pattern: /var/log/httpd/*log  weekly (8 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/httpd/access_log
  log does not need rotating
considering log /var/log/httpd/error_log
  log does not need rotating
not running postrotate script, since no logs were rotated


上記の場合は、weeklyで保存世代数は8で動いています。

意図した設定とは違っているという場合は、どこかの設定ファイルの内容が影響して悪さをしているかもしれません。

そのほか、logrotateの設定がうまくいかない場合は、関連記事も参考にしてみてください。





システムを作ろうとした時に、まずはサービスとしての立ち上げを優先するあまり、それ以外の事は時間ができたらと後回しにする事はよくあります。

しかし、規模が大きくなってサービスが軌道に乗ってくると色々とあの時やっておけばよかったとか、もう一度作り直したいという状況に追い込まれるのはよくある事です。

そんな事にならないように、初めからある程度考慮しておいたほうが良い事を書いてみたいと思います。



システム開発に関すること


1. フレームワークを利用する

一からシステムを組む際は、何らかの著名なフレームワークを最初から導入した方が効率的に進められます。

全てを手作りしたい衝動やフレームワークを導入する際の教育などのコストだけを見ていると、あとあと後悔する羽目になったりします。

それは規模が大きくなるにつれ、保守性がやたらと落ちたり、独自の構造から他のエンジニアがそれを使うのに習得するコストがフレームワークを使う場合のそれを上回る時がきたり、(その独自システムを作った人の自己満足が多く含まれる故に)そもそもそれを使ったところでエンジニアとして何もスキルアップ出来ない状況となったり、技術がレガシー化してサービスが対応出来ないといった課題が出てきたりするからです。


2. ログは残しておく

ログというのは思った以上に大事で、何も開発時のバグの発見やサポート時の状況調査に使われるだけではありません。

サービスのアクセス状況や行動履歴から有用な情報を得たりする事ができます。

前者は開発上どうしても必要となるため、ある程度目が向けられたりしますが、一定の期間があれば十分ということでその後捨てられ、後者の要件が満たせないということになったりします。

これは、ログサーバーの構築やバックアップの構成に影響してきます。

5年前のサービスインの時と今の状況を比較したいというような効果分析をしたいのなら最初から考慮すべき事となってきます。


3. 開発環境を整備する

規模が大きくなってくると多くのエンジニアが携わる事になりますから、個々のPCに入れるツールや開発サーバーの用意も必要になってきます。

規模が小さい場合、開発サーバーは別れているもののリリース前に確認するステージング環境と本番が設定分けているだけで同一サーバーだ、なんてのをよく見たりもします。

しかし、こういう状況は大きなリスクを負いますし、何よりもサービスを拡張していく上で足枷となってしまいます。


また、開発者が利用するPCやIDE等々の環境も整備しておいた方が良いでしょう。

これはエンジニアの能力を高めるだけでなく、環境の差から生まれる問題に頭をなやされるといった無駄な時間を解消してくれます。


4. スタンダードで実装する

フレームワークの件でも書きましたが、独自の実装を進めると大抵の場合はあとあとボロがでてきます。

世の中には先人たちが築き上げたベストプラクティスが幾つもあり、そして標準化された技術や高機能のライブラリも多数用意されていますので、それを使わない手はありません。

そういったものは、息の長い技術になってきますし、Tipsも多いためエンジニアの手助けをしてくれ、そしてスキルアップを助けてくれますし、何より変化に柔軟です。

世の中にないものを自分たちで作ろうとしない限りは車輪の再発明をするのはやめた方がよいでしょう。



システム保守・運用に関すること


5. 資料のアップデートを続ける

システム運用に関する資料は、設計書や操作マニュアル、障害時のリカバリ対応方法をまとめたものや、運用の体制からフローを定義したものなど多岐に渡ります。

開発当初はこまめにアップデートしてもリリース時点で既に整合性が取れてない資料がゴロゴロあるというのも珍しくありません。

これらの資料の作成やアップデートは優先度が引くなりがちですし、常に参照するわけでもないので、作業者のモチベーションもあがりません。


ただ、いざという時には必要なものになりますし、他のエンジニアへの引継ぎや教育などでは一から説明するよりは体系的に纏められたドキュメントがあった方が便利です。

この問題を解決するために、ドキュメントの管理方法やwikiを使うなどオンラインで手軽に使うためのツールやルールの整備も必要になってきます。

使わない資料を作るほど無駄の事はありませんし、誰が管理すると決められていてはなかなかアップデートも出来ないので、チームでそれを補う仕組みがあったほうがよいでしょう。


6. バージョン管理をすること

保守フェーズに入ってくると様々な機能の拡張や変更が行われます。

これはサービスの発展のためには仕方のないことですが、そのスピードが上がるにつれ内部仕様は複雑さを増し、問題もまた増えてきます。

プログラムのバージョン管理ができていないと、誰が行った作業かやいつから仕様が変わったのか、バグがどの時点で混入したのかの調査が難しくなります

保守フェーズにおいて、この作業にかける時間は馬鹿になりません。


また、バージョン管理はバックアップにも大いに役立ちます。

バージョン管理の扱いは多少扱いが難しいかもしれませんが、よくある直近のソースの状態をコピーしてから作業するといった事を続けるより遥かに多くのメリットをもたらせてくれます。
プログラムだけでなくコンテンツやドキュメントもバージョン管理の対象に含めておいた方がよいでしょう。

うっかり上書きしてしまったのであの時のドキュメントに戻したいとか、昔のデザインと見比べたいといった場合でも、瞬時に取り出せることで無駄な時間と労力を使わなくても済むようになります。


7. 自動化する

運用というのは作ってる過程ではおざなりになりがちで、よく「それは運用でカバーする」なんて言葉も聞かれます。

しかし、実際に運用が始まると苦労するのは担当者で、その後の施策の中で数多くの運用改善のプロジェクトが立ち上がり、その時間で本来のサービス拡張に手が付けられないという事態もでてきます。


また、手作業や人ありきの運用をしていると、サービスが大きくなるにつれ、その部分がボトルネックになり上手く回らなかったり、エンジニアもスキルが身につかなかったり属人化するリスクもでてきます。

運用のとこまで視点を広げ、 人の手をなるべく介さない業務作りも必要になってくるでしょう。



システム運営に関すること


8. 資産や契約を管理する

資産というのは機器だけでなくライセンスなども含まれてきます。

また、契約はそれに紐づくもので保守や請負に関する事など多岐に、そして複雑に絡んできます。

これをなぜ管理しないといけないかというと、まだ余剰で使えるものに無用な投資をする事を避けたり、契約期間が過ぎて保守が受けられなくなるというリスクを回避したり、それに伴う契約期間を考慮する事でシステムのライフサイクルやマイルストンを設定する事ができるからです。


システムはこの手の問題がつきまとい、構築当初は遠い未来のようでも、やがてEOS(End Of Support)を迎えるために次のリプレイスを検討しなくてはいけない時期がやってきます。

そういったリスクへの舵取りをうまくするためにも資産管理をしておく必要があります。


9. 役割を決め、専門職に任せること

サービスを作るには多くの役割とその担当者が出てきます。

そして、その道のプロも数多く携わるわけで、その人たちの成果物や意見に対して、素人は意見を挟んだり手を加えない方が良いでしょう。

デザインはデザイナーに任せた方が良いですし、サービスに対するイメージというのは上手く伝える必要はありますが、細かな色使いやレイアウトに意見することで本来の良さが消えることの方が多かったりします。

その意見は大抵、個人の意見だけが含まれた感覚的なものですので、広く受け入れられるとは限りませんから、その一言で本来の良さが消えてしまうどころか、そのままの状態で長く運用で引きずる羽目になってしまいます。

そして、その仕様に対して責任を取ってくれることはありませんし、次のリプレイス時には、口出しした人は恐らくいないでしょう。


10. 前に進めること

エンジニアは、ある程度の規模に成長したシステムを見て、小さな綻びがやたら気になり出したりします。

エンジニアの作り直したい病 でしょうか。


ここに書いたことを例えうまく見越していても何かの理由を付けて一から作り直したい衝動に駆られるものです。

しかし、大事なのはサービスとしての計画を一歩ずつ前に進めることです。
例えそれが後で問題がでるとしてもサービスを大きくすることを優先させなくてはならないことはあります。

同じ機能のために作り直す事はナンセンスで、それによる進化を盛り込まなくてはなりません。
後悔やモヤモヤとした感情を甘受することもまた必要な事となってきます。



まとめ


これらのことは、後々後悔することが多くありますが、その全てを見越すことは難しいことです。

わかっていても予算やスケジュールの都合で出来ないということもありますし、最後に書いたように後悔すると分かっていても優先度的に前へ進めなければならないこともあります。


ただ、初めからわかっていることと突っ走ってしまって後悔するのとでは大きく結果も違ってきます

何が何時の時点で問題になるのか、後で何をすればいいのかということを分かっていれば、そのリスクをうまくコントロールすることも出来るでしょう。




今年で35歳になるわけですが、最前線とは言えないもののなんとかプログラマとしての仕事も続けられています。

やっぱり現場は楽しいですし、自分が構築したものを他の人が使ってるのをみるとこの仕事をしてて良かったと思ったりするもんです。


ただ、この歳になってくるとなかなか若い時のように自分でガツガツとプログラミングをするというのは出来なくなってきます。

プログラマとしての仕事以外にやる事が増えて来たことで集中してコードを書く時間が確保できないこともあるのですが、プログラミングへのモチベーションを維持する事への難しさも痛感します。

それでもプログラマを続けたいという場合にどうすればいいのかと自分の立場を元に考えてみました。



若い子と一緒に仕事をする


一つは、若いエンジニアから刺激を貰うというのがあるでしょう。

自分自身もそうであったように、やはり若いうちは吸収力が半端ないと思いますし、何か蛇足で物事を考えて仕事するというような事もなかったりします。

純粋なコードを書く楽しさや作ったものが動く喜びを感じている彼ら・彼女らを目の当たりにしたら、そのエネルギーを貰うこともできます。


今の職場環境に若いエンジニアがいないというなら、Twitterなりブログなりで優秀な子たちが発する情報に触れて見るのもまた刺激になったりします。

35歳を超えてなおエンジニアを続けたいと思っている人は、昔にその楽しさや喜びを強く感じ取った事がある人かと思いますが、それであればなお今の若いエンジニアが発する生の声に刺激を大いに受けるかもしれません。


また逆にその若いエネルギーをいい意味で利用するというのもいいかもしれません。

次々と新しい事を吸収していく若い子は、新しい事へ取り組むハードルも引くく感じ取っていますから、自分たちが億劫になってることも難なくこなしたりもできます。

当然持ちつ持たれつの関係は必要でしょうから、自分の経験や知識というものを効率的に教え、その先の知識というものを吸収してもらい、フィードバックをもらうという循環を作れば、新しい技術を自分たちも得ることができたりします。



情報を追い続ける


昔から技術は日進月歩で耐えず進み続けています。

その情報に触れる事は、技術を陳腐化しないということの他にもモチベーションを維持することへの効果もあるでしょう。

情報だけを追っててもダメだという見方もあるでしょうが、若いエンジニアとは違い中堅エンジニアならではの情報分析もできます。

過去に幅広い技術に触れたことがあれば、一から学ばなくともそれがどんな技術なのかある程度理解する事ができたり、他にどんな技術と結びつくのかとか、それを利用してどんな事ができるのか、どんな事に転用できるのかと言った俯瞰的なものの見方もできます

若いエンジニアのようにすぐに手を動かすことはできなくとも、経験から効率的で違った角度から身につけることもできます。

しかし、情報を追ってないと自分の中にある技術はどんどん陳腐化していきます。

ブログやニュース系のサイトを見るだけと言っても、数多くの情報に目を通すのは中々骨が折れます。
特に技術系のサイトはコードが書かれていて全く理解できないものは読んでたら眠くなりますから。
しかし、今のテクノロジーのトレンドに触れることで、そこからこれは面白そうとか使ってみたいという想いも芽生えてきます。

それを使いこなしている他のエンジニアからエネルギーを貰えるというのもあるかもしれません。



環境を譲るのと新しい環境の開拓


組織の中ではどうしても若返りというものが必要になってきますし、コードを書くという仕事は経験の浅いエンジニアの仕事のように扱われます。

そして、中堅エンジニアはその役割を終わらされ、アーキテクトやプロジェクトマネージャーのような上位の役割を担うように仕向けられます。

35歳プログラマ定年説なんてのは、そういった企業が描くキャリアパスの中で生み出された風潮であるようにも感じます。

確かに何歳になっても現場で働くのに憧れもある一方で、自分が現場にいることで若い子たちの経験を奪う事への葛藤もでてきたりします。
なので、一つには今いる環境での役割を任せて自分たちは新しい環境でプログラマとしての地位を築くというのもあるかと思います。
例えば、会社を離れた場所で開発をするとか。

プログラマという仕事は比較的安価で仕事の環境を手に入れる事ができる職業ではないかと思います。
サーバーはレンタルでそれほどコストをかけずに借りれますし、後は自分のスキルを活かせば自由に開発作業もできます。
30代にもなってくると、ビジネスにも興味がでてきたりもするので、親しい人たちとサービスを立ち上げるとか、そういった新しい環境を作り出す事でプログラマとしての仕事を作り出す事もできるはずです。


そこは会社という組織に縛られない自由な環境ですから自分の想いのまま時間を使う事ができます。
会社の中でプログラマの立場から追い出されたならそれを作り出す努力も必要になってくるでしょう。



まとめ


やはりせっかく身につけたスキルであれば、それを活用しながらスキルアップしたいですし、何よりも自分が好きなこと得意な分野で仕事を続けたいと思います。

ただ、何よりも大切なのはエンジニアとしていつまでもいたいという自分の想いなのでしょう。

それを失っては、プログラマの仕事もいつまでも続けられないでしょうから。