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

A Day In The Boy's Life

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

アプリケーション上、日付を扱うことというのはかなり多いと思いますが、日付の比較やN日後の取得などその操作は結構面倒だったりもします。

Carbon はそういった日付操作を容易に行うことができるライブラリとなっており、導入もcomposer経由で簡単にできます。

 

 

Carbonを使ってみる

 

 

 

導入は、公式サイトに記載のとおりcomposerコマンドからインストールすることができます。

 

composerの使い方などは「[Composer] PHPのパッケージ管理にComposerを使う 」を参照。

Carbon自体はPHPのDateTimeクラス を継承する形で作られています。

 

<?php

namespace Carbon;

use Closure;
use DateTime;
use DateTimeZone;
use DateInterval;
use DatePeriod;
use InvalidArgumentException;

- snip -

class Carbon extends DateTime
{
- snip -

 

 

Carbonクラスはその中に定義されているstaticなメソッドやアクセサを使って操作します。

 

 

<?php

require 'vendor/autoload.php';
 
use Carbon\Carbon;

// 2016/03/03のオブジェクトを生成
$cb = Carbon::parse('2016-03-03 12:30:45');

// 2016年03月03日 12時30分45秒を出力
// フォーマットの書式はPHPのdate()と同じ
echo $cb->format('Y年m月d日 H時i分s秒');

// 個別に年月日時間を出力したい場合
echo $cb->year . "/" . $cb->month . "/" . $cb->day . " " . $cb->hour . ":" . $cb->minute . ":" . $cb->second;

// 1日後を表示(2016/03/04)
echo $cb->addDays(1)->format('Y/m/d');

// (この時点で2016/03/04となっているため注意)1週間前を表示(2016/02/26)
echo $cb->addDays(-7)->format('Y/m/d');

// (この時点で2016/02/26となっているため注意)1ヶ月後を表示(2016/03/26)
echo $cb->addMonths(1)->format('Y/m/d');

 

 

Carbon::parseにて、引数にセットしたい日付(引数無しの場合は今現在)を渡します。

 

表示したい場合は、formatで整形して出力といった具合です。

addDaysやaddMonthsなど(addYearsもある)でN日前後、Nヶ月前後を取得することが出来たりします。

Carbon::createにてクラスオブジェクトを生成することもできますが、こちらは引数に年月日を個別に渡すやり方になります。

 

$cb = Carbon::create(2016, 3, 3, 12, 30, 45);
echo $cb->format('Y/m/d H:i:s');

 

 

DBから取得した値をCarbonに渡すといった場合は、Carbon::parseのほうが便利かもしれません。

 

特徴的なのは、日付の比較などが簡単に行えることです。

 

// 2016/03/12の日付
$cb1 = Carbon::create(2016, 3, 12, 0, 0, 0);
// 今現在の日付
$cb2 = Carbon::today();
// 現在のコピー
$cb3 = $cb2->copy();

if ($cb1->eq($cb2)) {
    echo "日付は今日です";
} elseif ($cb1->lt($cb2)) {
    echo "日付は過去です";
} else {
    echo "日付は未来です";
}

// 1週間以内の日付かをチェックする
if ($cb1->between($cb2->addDays(-7), $cb3->addDays(1))) {
    echo "日付は1週間以内です";
}

// 1週間前からの日付差(7)を取得
echo Carbon::now()->diffInDays($cb2) . "日間の差があります";

 

 

eq(同一かどうか)、ne(同一ではないか)、lt(より小さいか)、gt(より大きいか)といった日時の比較や、betweenで指定の期間内かをチェックしています。

 

その外に、diffInDaysで日付差、diffInHoursで時間差を取得するといったことも出来ます。

 

また、その外に大きな特徴としてシステムの時刻を特定の日付にしてしまうということが出来ます。

 

これは例えば、未来の出来事でその処理が正常に行われるかのテストをしたいといった場合にとても便利です。

 

// 今日(2016/03/16)を表示
echo Carbon::now();
// 未来の日付(2020/04/01)をテスト的にセット
Carbon::setTestNow(Carbon::createFromDate(2020, 4, 1));
// 2020/04/01となっている
echo Carbon::now();
$cb = Carbon::today();
// 2020/05/01を取得できる
echo $cb->addMonths(1)->format('Y/m/d');

 

 

日付操作を全てCarbonに統一しておけば、設定の切替だけでテストが行えそうです。

 

 

このように、日付や時間を簡単に扱うことができるので、煩わしい日付操作をCarbonに任せてしまっても良いのではないでしょうか。

 

その他にも便利なメソッドも用意されているので、マニュアル も参照してください。

 

 

 

 

 

 

情報システム部門として社内の様々なサービスに対して社員から問い合わせ対応を行うようないわゆるヘルプデスク業務というのは欠かせないものとなっています。

自分はヘルプデスクというのはそんなに経験があるわけではないですけど、同じシステム部門に存在するものとして、また第三者視点でヘルプデスクを見ているとこういう風にしたらいいのにな、と思うことはよくあります。



ヘルプデスク業務は現場に委任したほうがいい


ヘルプデスクというのは、現場の人から何か不明点や困ったことへの問い合わせに対して応じるもので、そのサービスへの知識や理解もさることながらコミュニケーション能力というものが高く求められたりします。


ただ、このコミュニケーションというのは結構厄介なもので、ヘルプデスク側の人間もいろんな人がいるわけですから、当然品質は一定はしませんしやり取りする情報の中で傍目から見ていたらものすごく気になる細かい点がいっぱい出てくるわけです。

ここで、マネジメントする側がそのやり取りに介入して一つ一つ指示を与えるようなことをするケースが見受けられたりするんですけど、こうなってくるとマネジメント側がかなりボトルネックになってきますし、そんなことやるぐらいなら最初から自分でヘルプデスクやればいいのに、となったりします。

こうなると現場への介入ばかりしだして、マネジメント側が本来やるべき組織運営がおざなりになり、いつまでも現場は苦しい運用を続けなければなりませんし、メンバーのモチベーションも上がることはないのだろうと思ったりします。


もう1点、その品質を担保するために細かなマニュアルを作成して現場に配るようなケースもあったりするのですが、サービスは日々変化していくのでそのうちマニュアルが陳腐化していきますし、そもそもマニュアルを見ないと対応できないような人員ばかりが育ってしまい、後々組織として成り立たなくなることもありえます。

マニュアルなんか作らなくてよいというわけではないのですが、そういうものに注力するよりはヘルプデスクとしての指針を共有したり定期的な勉強会などを開いてメンバーのスキルアップを図っていったほうが長い目で見て効果がでてくるのでは、と思ったりします。



ヘルプデスクはエンジニアがやらないほうがいい


極端な言い方をすれば、ヘルプデスクにくる問い合わせというのはトラブル系を除けば、何らかのサービスに問題があるというものになります。

使い方がわからない、マニュアル通りにしてもうまくいかない、次に何をすればいいのかわからない、(サービスの仕様により)使えなくなってしまった、などなどサービス側でそれらがすぐにわかるのであればユーザー側もわざわざしたくもない問い合わせをする必要性もなくなります。

ですので、それらの意見・問題点を集約することでサービスの品質改善につなげていかなくては永遠にヘルプデスクへの問い合わせは減りません。


システム部門にヘルプデスクが必要な理由はユーザーを助けるという名目よりも、サービス品質向上に向けての位置づけでなくてはならないと考えています。

システム部門としては、サービスにおける問題点を集約するというよりは、それを解決することに注力しなければならないわけで、こうなってくるとヘルプデスクという存在自体をシステム部門で抱える意味が薄くなってきます。


ヘルプデスク業務をアウトソースするほど予算もないし、そもそもそんなに規模も大きくないから、という理由でシステム部門で開発者自身がヘルプデスクを兼任するようなケースというのは少なくないと思いますけど、こうなってくるとサービスと密接になっているため、適切な判断が取れない場合があります。

要は問い合わせというのはある種クレームというのも内包されているため、自身が運営するサービスにたいして意見をされるのは気に障るエンジニアとかも多いですし、進捗している案件に時間が取られるためにヘルプデスク対応に億劫になるケースがあります。


しかし、ヘルプデスクというのはサービス品質向上に向けて貴重な意見を集約できる組織体でもあるわけですから、エンジニアとの体制をうまく構築することで、その意見をサービス向上につなげるスキームを作ることもできます。

ですから、そのユーザーからの意見をエンジニアがダイレクトに受けるよりは、ヘルプデスクというクッションを挟むことで、サービスの良しあしが客観的にわかるようにもなるわけです。



まとめ


簡単に言ってしまえば、ヘルプデスク自体を現場主導としたチームで運営し、そこで集約したユーザーからの意見や現場でのノウハウというものをうまくサービス改善につなげていくような体制作りが必要なんだなと感じているわけですけど、実際のところはクレーム処理を押し付けられていたりと、ヘルプデスクの現場にもユーザーにも運用回避する手段を押し付けているようなのが現状だったりもします。


組織の上の人たちも、このヘルプデスクという業務の必要性は理解しているものの、その存在価値や活用方法というのはあまりわかってないのではないでしょうか。

問い合わせの件数というのは定量的に推し量ることが簡単ではあるのですが、それがサービス改善にどう結び付いたのかという効果を推し量るのはなかなか難しいことで、実際にヘルプデスクの現場から生まれた改善であることを明確化したり、その効果を測定する仕組みを用意することで組織としての存在価値を認めてもらう必要性があると感じたりしています。





システム担当者なら誰しも巻き込まれるシステムトラブルですが、なんでこんなことにと悩ますような怪現象に巻き込まれることがしばしばあったりします。

例えばこんな・・・。



システム入れ替え前に現システムのトラブルが頻発する


数年ごとにシステムをリプレイすることがあったりしますけど、その直前に現在稼働しているシステムにトラブルが頻発することがあります。
エンジニア側から見れば、「もう少しでリプレイスするんだからそれまで我慢してくれよ」と思うわけですけど、「私なんてもう必要ないんでしょ!」とばりに今のシステムが機嫌を損ねてくるわけです。


で、こういう場合にエンジニアとしてはあんまり本気で対策を取りたくないわけです。
もうすぐ新しい環境に入れ替えるわけですから捨てるシステムにそれほど多くの労力を費やしたくないわけですし、そもそもリプレイスの作業のスケジュールが差し迫っている中、そちらに割く時間も多くは取れないわけです。
暫定的な対策で機嫌をごまかしつつこの日まで何とか持ってくれと祈るような気持ちで見守るもやもやした日々がリリース日まで続いたりします。

これはある程度システムやハードの寿命というのが間が悪く訪れる現象だとは思うのですが。



担当者不在の時に限ってトラブる


自分がそのシステムに一番詳しい場合、よりによって休んだ時に大きなトラブルが発生し、同僚とかからの電話に出る羽目になりせっかくの休みが台無しになることがよくあります。
また、他の担当者の場合でもトラブルが発生した時に事前の変更作業が共有されていなかったり、いつもは静かなのにその日に限ってやたらと問い合わせが入って詳細な仕様がわからずに多くの時間を調査に割かれることになったりします。

まぁ、この辺は保守・運用の問題でもあるわけですけど、多くのシステムを抱えていたりするとあの人が一番詳しいというのは出てきたりするわけで、そういう部分をついたトラブルや問い合わせや調査の依頼などが来て頭を悩ませることがあったりします。

休んでるだけならまだ連絡のつけようがあるのでいいんですけど、リリース前にエンジニアが辞めるなんてこともあったりして、その場合はなお悲惨な状況になるわけです。



何もしていないのにトラブルが直る


トラブルが発生して様々な調査にかなりの時間を費やしたにもかかわらず、原因が特定できずに途方に暮れている中で、特にシステムに変更を加えたわけでもないのに突然問題が解決するということがあったりします。
結局何をしたのが原因か、どこに問題が起きたのかわからず担当者はみな狐につままれた気持ちになるわけですが、調査も行き詰まりを見せると「タイミングの問題かね」なんてわけのわからない言葉でトラブルを闇に葬り去ろうとしたりします。

まぁ、逆のパターンの「何もしていないのにトラブる」というのは大体何かをしている場合で、まずいことを起こしたユーザーはたいてい「何もしていない」ととぼけられたりするわけですけど、ログとか追っていると明らかに何かしている痕跡がでてくるわけで、そういった無駄な調査に多くの時間を取られて疲労感いっぱいになったりもするわけです。



トラブルは連続して起きる


一つのシステムトラブルでいっぱいいっぱいになっている最中、別のトラブルに巻き込まれるといこともよくあり、なんで今日に限ってこれが起きるのかという気持ちになったりします。

こういうのはシステム間で全く無関係のように見えて実は関連性があるものであったりもするのですが、連続して全く別物のハードウェアが相次いでお亡くなりになるということもあったりして、凄惨を極める一日になったりすることがあります。

まぁ、炎上しているプロジェクトの場合で課題が次々と発生するのと同じことではあるんですけど、連続してトラブルが起きると担当が不足することもあり、関係ないシステムトラブルの対応に巻き込まれたりしてエンジニアが相次いで倒れる状況に陥ったり。



帰る頃にトラブる


さて、そろそろ帰るかと思ってたらシステムトラブルに関するアラートメールが発砲されてきたり、ユーザーから電話がかかってきたりすることもよくあることです。

24h/365dなサービスが多くなる中でシステムトラブルの時間を選ぶことなんてもちろんできないわけですけど、対応する側としては日中帯に起きてくれれば多くの時間が取れたのにという気分にもなったりします。

これがハードウェアの問題になってくると保守業者へ連絡して対応を待ったり、遠隔地に機材がある場合はそこへの移動を考えなくてはならなくなり、終電のことが頭をよぎったりしてどこまでを今日中にやるかという時間との別の戦いも始まります。

トラブルが起きたのがよりによって平日日中帯のサポートしか受けれない保守契約だったりして途方に暮れることもしばしばあります。



まとめ


まぁ、要は間が悪いときに限ってトラブルが起きるというものなんですけど、中の人にとっては結構なんでこのタイミングでその問題が起きるの?って気持ちになるわけです。

どこまでリスクヘッジをしておくかということでもあるわけですけど、可能性としては低いであろうことが当然のように起きたりします。

まぁ、そのリスクヘッジにかけるコストも当然捻出できなかったりして余計に頭を悩ませることになったりするんですけどね。