テクニカルサポートの範囲のお話

f:id:sugitk:20210602121040p:plain

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。

先日公開しましたこの記事なのですが、反響が思いのほか大きく、多くのご意見をいただきました。さまざまな立場の方に見ていただいていることを忘れ、配慮に欠けた表現がありましたことをお詫びします。内容としましても不正確な部分が含まれておりましたので、改めて修正したものを再度公開します。

毎日世界中からさまざまな問い合わせを受けている中での経験なのですが、「思ったように動かない」ときの原因としては、例えばこのような設定に起因することが多く見受けられます。

  • ファイアウォールで必要なポートを閉じている
  • 権限をデフォルト値から変えている
  • 必要な設定ファイルを書き換えている
  • サポートされない組み合わせで使っている
  • リソースが足りていないのに無理矢理動かしている
  • 正常な動作を阻害する可能性のあるサービスを稼働させている

などなどです。

製品を導入して実行していただく環境はお客さまによってさまざまで、制約もそれぞれ異なるものがあります。その制約に適合するように設定を変更して運用いただくことは自由に実施していただけますが、製品サポートの立場から見ますと、その設定では動かないこともありますねという場合があります。もちろん製品自体に不具合があって動かない可能性もありますので、再現して解決策を早期に提示できるよう、問題の切り分けのためにご協力をお願いすることがあります。

推奨する設定から変更される場合にご不安なことがありましたら、あらかじめご相談いただけますと運用時にトラブルを起こす可能性を軽減させることができます。

テクニカルサポートの範囲

運用を進めていきますと想定しないことが多く起こるものです。テクニカルサポートは、インストール時や運用中に発生した不具合の調査や解決を目的としています。

わたしが担当する製品の Ansible のテクニカルサポートで対応する範囲については、こちらでご案内しています。他の製品でも同じようなドキュメントを用意しています。

access.redhat.com

access.redhat.com

access.redhat.com

このテクニカルサポートの範囲に限らず、レッドハットでは、お困りごとの内容に応じてさまざまな受付窓口を用意して対応しています。

Ansible のテクニカルサポートが対応する範囲外のこととして比較的多くいただくのは playbook の書き方やデバッグについてのお問い合わせなのですが、テクニカルサポートではお手伝いすることができません。状況によってはラーニングサービスをお勧めしています。RHCE をはじめ、Ansible のラーニングコースも目的に応じて用意しておりますのでご検討ください。

www.redhat.com

また、システム設計時の検討のために必要なこととして製品全体の仕様確認や、ドキュメントに掲載している内容の解説を求められることがありますが、導入される前段階でのお客さま固有の事情を加味した設計支援については、コンサルティングサービスをご案内しています。他には、お客さまの運用標準に適合するために例えば設定項目を羅列して Excel 表に穴埋めしてほしいということや、バージョンごとの差分を列挙してそれぞれ解説してほしいというご要望を受けることがありますが、テクニカルサポートは作業のお手伝いはできませんので、こちらも合わせてコンサルティングサービスのご利用を検討いただくようご案内しています。

www.redhat.com

お客さまの場面や状況に応じまして専門の担当者がそれぞれの範囲をカバーしていますので、詳しくは営業にご相談ください。

  • プリセールス: ご購入前のお問い合わせ
  • コンサルティングサービス: お客さま固有の課題を含めた製品の活用を支援
  • テクニカルサポート: インストール時や運用中に発生した不具合の調査や解決
  • ラーニングサービス: 製品の学習

問い合わせをする前に

特に海外のお客さまからは「動かない!電話してくれ!zoom のURLはここだ!重要度は1だ!!」とだけお知らせいただくこともあるのですが、では一緒に見てみましょうとすぐ立ち向かっても、なかなかすぐには問題解決に結びつきません。

どのOS上でどのバージョンをどのような構成で稼働させているのか、何を操作したときに動かなくなったのか、環境の問題なのか設定の問題なのか、もしくは動かそうとしているジョブに問題があったのかなど、数多くの想定される原因を分析する必要があり、切迫された状況の中でリアルタイムに情報を収集して解決に導くということは容易ではありません。

初動を早めるために、お客さま独自のそういった稼働状況を熟知した専門の担当者をTAMとしてご契約いただくこともできます。普段の運用状況を定期的にご共有いただくことで問題が発生したときの迅速な対応ができたり、お客さまの目的に合った製品についてのご案内を提供したりなど、さまざまな利点がありますのでご検討ください。

www.redhat.com

TAM のご契約がない場合には、我々テクニカルサポートエンジニアが直接対応します。幸いにも Ansible は世界中の非常に多くのお客さまに導入いただいておりまして、さまざまな構成や状況で稼働しています。バージョンによっても問題の絞り込み方が異なるものもありますので、まずは基本的な情報収集から着手します。

Ansible Tower の場合ですと、まずは基本的な API を呼び出していただいて構成状況の把握から始めます。例えば2月に書きましたこちらの記事のように、申告いただいた問題に応じて必要な情報の収集をお願いしています。

rheb.hatenablog.com

上の記事でも触れておりますが、ログやプロセスなどの情報を取得するために、RHEL に付属する sosreport を求めることもあります。これは OS に関するさまざまな情報を収集して一つのアーカイブにまとめてくれるものです。どんなものが収集されて、サポートエンジニアは何をまず見ているのかということにご興味あれば、お手元の検証環境で一度お手元で実行してみてください。Ansible Tower を導入されている場合での実行では大きな問題となる可能性は低いのですが、他の製品では状況によって多くのリソースを消費することがあると聞いていますので、お試しされる際には安全な環境で実施いただくことをお勧めします。

access.redhat.com

製品の仕様を理解されているお客さまですと、ある程度特定されたログやスクリーンショットを共有いただいて問題を追跡していくこともあります。問題が発生しているときにはログレベルを変更したいこともよくあることだと思いますので、そのようなエラーメッセージはどこに出力されるのか、より冗長なメッセージを出力するにはどうするのがよいかというお問い合わせもよくいただきます。

Ansible Tower の場合ですと、まずはこのあたりのファイルを見ていきます。

  • /var/log/tower/*.log
  • /var/log/supervisor/*.log
  • /var/log/nginx/*.log

エラーメッセージが出ることがわかっているのであればあらかじめ網羅しておいてキーワードを決めて監視したいという要望もあります。しかしながら、多くの要素が複雑に関連している現代のソフトウェアにおいては、厳密にエラーメッセージを網羅することは現実的に不可能です。サービスとして全体を捉え、個別の事象を深く追跡することよりも、問題が発生した後の修復を行う方法を確立していくほうが価値が高い場合もあります。

また、エラーメッセージは通常は英語で表示されます。特に日本ではログをご提供いただくことが難しいお客様もいらっしゃいまして手で書き写されてくることもあるのですが、その際に綴りが正しくないものをいただくこともありまして、問題の理解に非常に時間を要します。平易な英語で書かれておりますので、お伝えいただくにしても何が書かれているかをご自身でも読み取っていただくことをまずお勧めします。画像ファイルや Excel 表などに加工せず、できるだけログファイルを直接そのままいただけたほうが問題解決にスムーズにつながりますので、ご協力いただけましたら幸いです。

製品の動作要件

運用のルールはそれぞれのお客さまごとに秘伝のタレのようになっていることも多く、製品の仕様や世の中の標準が随時アップデートされていくという中であっても、さまざまな制約を受けて一度決めた方法をそのまま踏襲していくということが行われている場合があります。

一般に製品を利用する場合には出荷時そのままの設定で使うことがもっともリスクが低く、独自に設定を変更していくことで問題が発生したときの追跡がどんどん困難になります。

具体的には、例えば「RHEL 7.4 を使うこと」と会社標準で決めてしまっている場合に、3年経ってもその標準をアップデートしなかったために、現在サポート対象となっている製品を動作させることができないということがありました。他にも、umask 0022 で使ってくださいとマニュアルに記載しているにもかかわらず、ルールとして適合しないからと umask 0077 などで利用されているために思いがけず動作しなくなるということもあります。そのような制約としては各お客さまの運用ルールや各国の法律、サブスクリプションの費用やクラウドサービスの運用費用の節約など、さまざまな要素を複雑に検討して決められていることが多いようです。

そのような事情があることは理解しておりますが Ansible はほかの製品と比べますと非常にライフサイクルが速く、ほぼ毎年アップデートしていくことをお願いしています。さらに、リリースノートには記載しておりますが、次期メジャーバージョンの Ansible Automation Platform は RHEL 7 では動作しないものとなる予定です。Ansible は普段運用されているシステムの外から制御対象に対して SSH 等で接続して自動化を行うものですので、Ansible だけでも速いライフサイクルに沿ってアップデートを見据えた運用をされることをお勧めします。

新しいものに追随しながらサービスを安定稼働させるためには、商用環境と同等の検証環境によるテストを常時実施していただくことが必要です。Ansible に限らずどの製品にも CI/CD を考慮したテストやデプロイの仕組みが整っていますので、積極的にご利用いただきたいです。

リソース

Ansible の場合では、他のアプリケーションも同様にリソースとして CPU、メモリ、ストレージ、ネットワークを使用します。ストレージは比較的わかりやすくファイルとして計測しやすいため、積み上げで予測しやすいものとなっています。ネットワークの帯域についても、Ansible の場合は SSH で接続して小さなプログラムを送り込むという性質のものであることから、よほど大規模でない限りは、大きな問題となることは少ないようです。

しかしながらCPUやメモリのリソースの見積もりは簡単ではありません。「この playbook を動作させるためにはどれだけメモリを必要としますか」という簡単な問いに答えることも困難です。機能を動作確認するために最低限必要なリソース量はマニュアルに記載していますが、実際にお使いの環境でどのリソースがどれだけ必要になるのかについては、しばらく稼働させてみて様子をみていただくことをお勧めします。

Linux カーネルにはコントロールグループ (cgroup) の機能がありまして、稼働するプロセスに制限をかけたり、計測したりすることができます。

access.redhat.com

Ansible Tower でもこの cgroup の機能を利用したプロファイリングを有効化する設定がありますので、必要であればご利用いただけます。

docs.ansible.com

このような情報取得についてのお手伝いはできますが、実際にその内容を分析したり、設定の助言を差し上げることはテクニカルサポート範囲からは外れます。コンサルティングサービスにご相談ください。

おわりに

我々サポートエンジニアは製品の使い方についてのお問い合わせや問題解決だけを担当しますので、実際に長らく運用されているお客様がどのような工夫をされているのか、Ansible であればどんな制御対象に対してどんな自動化をしているのかということについては、実のところあまり触れる機会はありません。製品に詳しくなるにつれて、Ansible がどのように世の中に役に立っているのかを知りたくはなるものなのですが、日々の業務に忙殺されていますとその機会が少なく、歯がゆく感じているところがあります。

そんな中で実際によくやりとりされているお客様になりますと、これがうまく動くようになったことでこんなことも実現できるようになったとお知らせいただくこともあります。大規模なお客様の事例を見ますとビジネスも非常に大きく、問題解決のお手伝いができたことで一緒に何かを成し遂げたように感じることもあります。

Ansible はありがたいことに国内外さまざまなお客さまにご利用いただけるようになっていますので、グローバルのさまざまな事例に触れる立場から、何か日本のIT業界に対しても還元できるところがあればと思っています。Ansible はIT自動化ツールですので、従来の方法ですと100台程度までしかできなかったようなことが、数千台や1万台に対しても大きなコストを掛けずに制御することができるようになることがあります。さまざまな成功事例がありますので、お客さまのビジネスをより拡大していけるよう、テクニカルサポートの立場ではありますがお手伝いしたいと考えています。

技術的にも Ansible が扱う範囲は非常に幅広く、サーバやネットワーク機器、クラウドなどさまざまなものに及びます。今後は OpenShift や Insights のような弊社の他の製品とも連携が強まっていきますので、これから進化していくのも楽しみにしています。毎月のようにユーザー会がもくもく会のイベントを開催していますので、ご興味持たれましたらご参加ください。

ansible-users.connpass.com

最後になりますが、当初公開した記事では読者の立場によってはご不快な内容もあったことを重ねてお詫びいたします。

Ansible Automation Platform の評価ライセンスリクエストはこちらからご利用いただけます。

www.redhat.com

Happy Automation!

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。