アルファラボでの1日：Java開発

多くの場合、会議に参加する企業と技術面接を行います。 しかし、 Alfa-Bankの IT部門では、1人の開発者に質問を送信するだけでなく、オフィスで1日を過ごして、バックベンダー、フロントエンド、携帯電話を設置します。 結局のところ、全体像があります-使用される技術から会社の一般的なアプローチまで。

彼らは1つの「フルスタック」テキストを作成しようと考えましたが、非常に多くの資料があったため、それを部分に分割する必要がありました。 そして今、あなたが「朝」の最初の部分であり、彼らはJava開発者マキシム・ゴレリコフとキリル・ トルカチョフと話しました。 両方とも最近ジョーカー会議で話をしました。

マキシム・ゴレリコフ

-最初に、会社にどれくらいの時間を費やしているか、最初にどの職に就いたか、そして今何をしているのか教えてください。

-2015年半ばにアルファに来ました。 昔、私は多くのものを開発し、建築に携わっていましたが、やがて私はティーポットであることに気付きました。 Senseチームのメンバーが私に話しかけ、電話をかけてきましたが、断ることはできませんでした。テクノロジースタックは非常に興味深いものでした。

聞いたことがない方は、Senseは銀行内のそのような新興企業であり、モバイルアプリケーションの形の個人的な財務アシスタントです。 彼は毎年恒例のハッカソンで生まれました。 アイデアとプロトタイプはうまくいき、プロジェクトとそれを思いついたチームにお金が割り当てられました。 センスはまだ生きていますが、一般的に、その機能は現在、銀行のメインアプリケーションに徐々に移行されています。

一般的に、私はここで純粋な製品チームのJava開発者として始めました。 数年間、私は多くのことを学び、さまざまなプロジェクトに参加し、現在は主にインフラストラクチャ、開発者向けツール、安定性タスクに取り組んでいます。

-おもしろいですが、ハッカソンのアイデアを銀行の本当の商品に変えたのですか、それとも他の例はありますか？

-孤立したものではありません。 たとえば、昨年、開発者のみで構成されるチーム（製品の所有者、デザイナーなどを持たない）によるハッカソンに参加しました。 チームは非常に緊密に連携しました。実際にラップトップを24時間放置しなかったため、最後にはレモンのように絞られました。 そして、他のアルファ開発者を対象としたプロジェクトがありました...「プラットフォーム」という言葉を発音するのが怖いのです。 「プラットフォーム」を開始した理由：

会社は積極的に成長しており、私たちは常に希望する経験を持つ人々をすぐに雇うわけではありません。 時々、新参者はほとんど経験がなくても目が燃えます。 JUGミーティングの後、人々は来て見回ります。「ああ、シリルが通り過ぎました！」 彼らは学ぶためだけにここに来ます。 そして、そのような人が最初はfireを壊してすぐに参加しなかったように、ある時点で、入場のしきい値を下げるようなプラットフォームを作成することにしました。 テンプレートとライブラリを使用してサービスをすばやく作成できます。

ある時点で、私たちはそれを理解し、新しいチームがJIRAでプロジェクトを設定するのに多くの時間を費やし、ジェンキンを自分自身で育てることに気付きました（すべてのジェンキンに座るのは大きなリスクです。 。 開発者がボタンを押し、JIRAでプロジェクトを設定し、Jenkinsでジョブを作成するなど、コードを生成し、何らかのサービスベースでプルリクエストを作成するまで、これらすべてを統合しました。 このもののアセンブリが表示されたら、開発者はデプロイをクリックすることができ、テストのためにすべてが展開されます。 これにより、開発者はすぐにすべてがどのように起こるかを理解し始め、この製品に採用されているサービスの基本構造を見て、そのスタイルを理解します。

-そして、ハッカソンのプロジェクトは、銀行の本当のニーズに沿ったものにする義務がありますか、それともまったく違うことをすることができますか？

-楽しみのためだけに作られたクレイジーなアイデアがありました。後で真剣に宣伝することは意味がありませんが、その過程で誰もが多くの喜びを得ました。 たとえば、ハッカソンの1つで、シリルと大規模なチームがスマート冷蔵庫を作りました。 これは一般的に銀行の主要製品には適合しませんが、24時間の楽しみでした。 私たちは座って、はんだ付けし、ある種の食料品店を解析しました。 真夜中に、彼らは突然冷蔵庫がなかったことを思い出したので、チームの一人が夜にそれを持って来て、そのようなZILに値しました：



私は一般的に、アルファを実験の精神がある場所だと考えています。 チームに7人がいる場合、これらはすべてのレイヤー（JavaからiOSまで）の開発者であり、開発者の宗教に従ってインフラストラクチャを編成することもできます。これにより、スタートアップの雰囲気が維持されます。 このチーム自体がすべての問題を解決し、決定を下すことができます。

-通常、「銀行」という言葉は「実験の精神」という言葉ではなく、安全、注意、保守主義という言葉に関連付けられています。 あなたの条件下でどれくらい実験できますか？ Kotlinのような「興味深いが、まだ業界標準ではない」何かを使用できますか？ また、JavaまたはSpringの新しいバージョンがリリースされたとき、どれくらい早くそれらに切り替えますか？

-いずれにしても安定性が必要であることは明らかです。 しかし同時に、新しいものを直接本番環境にドラッグする必要はありません。 技術的なバックログにはかなり多くのタスクがあります。 いくつかのツールを作成します。完全に満足できる既製のものがない場合は、試してみてください。

さらに、銀行のSenseのようなプロジェクトには、パイロットステータスがある場合があります。 つまり、小さなクライアントベースがあり、そこにいくつかのことを試すことができます。 そして、現在Alphaにあるスタックの一部はSenseから、一部は他のプロジェクトから来ました。 実験の余地があるとだけ言っておきましょう。 もちろん、GitHubで3つ星を獲得しているリリース候補やテクノロジーを争うことはありません。 しかし、新しい技術を持ち込むために根本的な問題はありません。

決定は、製品に取り組んでいるチームによって行われます。 3つの開発チームが座り、コトリンを戦闘に引きずり込みたい製品がある場合、彼は他のチームからジャビストを説得する必要があります。 そして、会社全体でそれを普及させるために、そしてこれが初心者に推奨されたために、彼は他の製品で人々を説得する必要があります。

新しいバージョンへの移行速度について-ケースごとに、実際にどれだけ必要かによって異なります。 Java 9では、プロジェクトはまだ移動していないようですが、それほど前のリリースではありませんでした。 しかし、Spring 5では、積極的に実験を行っています。最近のジョーカーでは、それについて話していました。 時間が近づいており、興味深いチップがあります。たとえば、Spring Boot 2.0がリリースされるとすぐに、その上のマイクロサービスの一部を追い越すことが可能になります。 ほとんどの場合、「リリースがありました-来週または今週の終わりにいくつかのマイクロサービスが表示されます」というカテゴリから、いくつかのマイクロサービスのかなり迅速な移行が行われます。 マイルストーンバージョンを既に試したので、リリースでは、どのバグが既に閉じられ、どの重要なバグが残っているかがわかるので、自信がつきます。

-そして、法律の側からの厳格な要件（「そのような情報を保存する」）およびセキュリティ（「この情報が部外者に利用可能にならないようにする」）は、空想を飛ぶ代わりに、ポイントで1,000の退屈な要件に対処する必要があるという事実につながりませんか？

-それどころか、これはまさに実験のための素晴らしい空間です。 過去に、Joker Ilya Sergeevはログインフラストラクチャについてレポートを作成しました。このレポートでは、これまで試したことのないあらゆる種類のさまざまなテクノロジを試しました。 また、このインフラストラクチャは、特定の情報を特定の保存期間と特定のユーザーグループのアクセスで保存する必要があるときに生まれました。

その前に、ログをElasticに直接ロードしましたが、この場合、ダッシュボードとモニターを構築するのが便利ですが、そこから大量のデータを一度にアンロードしようとする誰かを許可した場合、それらはすべてそれを置く可能性があります。 そして、Kafkaとキューを介してロギングインフラストラクチャを構築しました。これにより、これを操作する必要があるユーザーがいつでもこのキューに入り、そこから最新のデータをアンロードできるようになりました。 そして、それらがどれだけの形でどのように保存されるのか、これが彼らの仕事だとしましょう。

私たちと一緒に実験したい人は、常に何を見つけるでしょう。

もちろん、セキュリティのため、アクセスの発行に関して制限があります。 「すべての実稼働クラスターがインターネット全体にアクセスできるわけではない」というカテゴリーから。 パイロットにはもう少し行動の自由があります。 多くの顧客がいる深刻な製品は、リスクが大きくなります-より困難です。 時々、警備員と交渉します。 時々、アクセスする必要がないようにインフラストラクチャとそれを操作するツールを構築します。手動で何も設定しないようにします。すべてが自動です。



-側から見ると、銀行はわずかな遅延に対して罰則を課せられた厳格な組織のように見えるかもしれませんが、実際には、労働時間は決まっていますか？

-いいえ。 昨日新しいハードウェアが到着し、新しいロギングクラスタに移行し始め、新しいスキームを導入し、全員が遅く解散したため、Cyrilはまだオフィスに現れませんでした。

しかし、この自由度により、個々のチームはしばしば独自の規律慣行を導入します。 チームの毎日のスクラム会議があり、DSMに遅れたために少額の罰金を課すことが決定されました。 チームのDSMは11:30であり、銀行はすでに具体的な金額を蓄積しています。 もう少し貯めて、このお金のためにバーに行きます。

-IT部門とアルファバンク全体のコミュニケーション構造はどのようなものですか？通常の開発者は、IT以外の人と多くのことをやり取りし、彼らから指示を受ける必要がありますか？

-通常、特定の製品の製品所有者は銀行の製品委員会で計画について話し合い、チームとこの計画の実装の技術的な詳細を理解します。 同時に、彼は「銀行から2枚のTKを受け取る」だけでなく、すべてがより柔軟です。 製品オーバー自体がアイデアをもたらし、指示に従って明確に機能しません。

実際には、決定は製品提供者だけではありません。 通常、チーム全体が製品の作成に関与しており、主な質問が時々聞こえます。



チーム全体が何が行われているのか、そしてその理由を理解していれば、何か質の高いものを簡単に作成できるようになります。 チーム全体が責任を負うため、全員に投票権があります。

-そして、Alphaの開発者は、融資を許可する特性など、銀行の特定性にどれだけ没頭する必要がありますか？

-チームと開発者に依存します。 それに深く没頭している人々がいます。私は彼らが興味を持っているという理由だけで会計をマスターし始めた人々さえ知っています。 しかし、私がアルファに来たとき、最初の年、私はほとんど詳細に突入しませんでした。 銀行サービス、APIとやり取りして情報を取得するために必要な一連のドキュメントがありましたが、その場で銀行の詳細を理解する必要はありませんでした。

ここで長く働くほど、一目ですべてをカバーし、プロセスとアーキテクチャを構築しようとすればするほど、それが最初から最後までどのように機能するかを理解する必要があることは明らかです。 しかし、最初の段階では、頭で渦に飛び込んで支払い、投稿を理解し始めるようなことはありません...チームのアナリストは通常​​、この質問を閉じます。

-「一目ですべてを一度にキャプチャしようとする」という質問に対して、「製品チーム以外の」より一般的な役割に切り替えたと既に述べていますが、詳細を教えていただけますか。

-はい、経験が積まれても...私はそれを成長と呼ぶつもりはありません。たとえば、開発者の「方向転換」です。 ほとんどの場合、開発者が来ると、彼は製品チームに突入し、仕様、原則、プロセスを徐々に理解します。 最初の数か月後、彼は同化され、「すべてが新しい」という状況がなくなったとき、彼は他の補助機器に従事し始めます。 そして、彼はすべての技術を理解し、新しい技術を取り入れることができ、他の開発者とこれを議論する方法を理解するまで成長すると、ほとんどの場合、彼は目立つようになり、フルタイムのチームで作業を停止します。 彼はむしろ技術を実験し、いくつかのプロトタイプを作成し、初心者がそれに慣れるのを助け、技術的なバックログを処理し、他の人を引き付けます。 彼は、どこが不安定なのか、何を引き上げる必要があるのか​​、どのテクノロジーまたはアプローチを実装するのかを見ています。

さらに、そのような役割は、「アーキテクト」または「チームリーダーであるチームリーダー」の標準的な定義に適合しません。 そのような人はコードを書く義務があるので、彼はインフラストラクチャに対処する義務があります。 ただ座って、ヒントを左右に配るだけですか？ 少なくとも1か月または2か月の間、開発プロセスから外れると、通常はチーム内の開発者を理解しなくなり、何か新しいものをもたらします。 そして、そのような人々は、チームに何かを持ってきて、他の人にこのレベルに到達する必要があります。



-チームの独立性とチーム内でのやり取りについて話しましたが、チーム間のやり取りはいくらですか？ そして、あるチームから別のチームにどのくらいの頻度で移動しますか？

-もちろん、相互作用は十分です。 チームにジャビストが1人しかいない場合、彼は退屈している可能性があり、Javaトピックで通信したい場合があります。 私たちの人々は積極的に会議や会議に参加しているので、どのような場合でもコミュニティに参加できますが、Java開発者のコ​​ミュニティもあります。 私たちは、単に興味深い問題について話し合うだけの夕方の会議を開催します。人々がトピックを投げ、投票し、構築し、議論します。 1時間以内、または（議論する欲求が終わらない場合）無限に、これは通常金曜日の夜に起こります。 誰かが会議の前にレポートをリハーサルすることがあります。 銀行の話題、時には一般的な技術の話題について話し合うこともありますが、コトリンのファンが来て、「コトリンのコルーチンについて話し合いましょう」と投げかけることができます。 そして彼女は行きました...

通常、別のチームに行くことは問題ではありません。 チームは互いにコミュニケーションを取り、他の人が何かをしたい場合は、2人のジャビストを変更し、新しいジャビストを見つけることができます...また、プロファイルの変更も可能です：自分自身にまったく新しい何かを学びたい場合は、チームメイトに行くことができます「ペティヤ、そこで開発を試みるのは面白いでしょう。 私に教えてもらえますか、私の指導者になれますか？」 彼はあなたに小さなパズルを与え、あなたとそれをします。 これは定期的に行われ、人々が開発します。たとえば、開発者がフルスタックで開発し、テスターが開発を開始します。

まったく新しいプロジェクトをやりたい場合は、ハッカソンでプロトタイプを作成するか、内部のmitapの1つでそれについて話すことができます。

-Alfa-Bankには、モバイルアプリケーションのような製品があり、一般の顧客（Habrの読者を含む）にはっきりと見えるようになっています。 自分が取り組んでいる、または取り組んできたプロジェクトの例を挙げてもらえますか？

-最近、ニュースで、 彼らはアルファバンクとスベルバンクの間のブロックチェーンを介した銀行振込について書いたが、これはブロックチェーンでの私たちの最初の経験ではないことはあまり目立たなかった：昨年、アルファバンクとS7はロシアは 、その助けを借りて信用状取引を実施しました。 前述のイリヤ・セルゲイエフにとって、ブロックチェーンで作業することは興味深いものでしたが、それを試すためだけに新製品を発売することではありませんでした。 そして、銀行から紙の流通を減らす必要が生じました。 それで、2つの孤独が会いました。

-ブロックチェーンの見通し（技術的および法的両方）はまだ完全には明らかではありません-会社がこれにリソースを投資するのは怖かったですか？

-私たちは時々、一見すると「離陸する/離陸しない」という質問を提起するものを立ち上げます。 何百万人もの人々が使用している製品の何かを変更すると、「素晴らしい、最後に」多くのレビューと「なぜやり直す」多くのレビューを同時に受け取ることができます。 また、新しいテクノロジーを導入する場合、プロトタイプでテストするまで何が起こるか正確にはわかりません。

安定性は私たちにとって間違いなく重要です。私たちはまだ銀行です。しかし、何か新しいものを実験して立ち上げなければ、遅れることがあります。

キリル・トルカチョフ

私たちはその日遅くに来たキリルに尋ねませんでしたが、後で私たちの会議でジョーカーを捕まえて、彼の後にいくつかの質問をしました。

-あなたはすでにJavaの「Javaオーソリティ」にいます。Alphaの開発者からは、「そしてCyrilに尋ねに行った」という文脈であなたのことを聞くことができます。 自分でたくさんのコードを書いていますか？

-既存の技術スタックは、私も含めて結成されたものであり、それ自体で、それについての質問がある場合は回答します。 多くの場合、人々は私たちが考えられないケースを持って来て、興味深い話をし、一緒にこれを修正する方法を考えます。 最近到着した開発者は、自分が嫌いなことを積極的に発言し、なぜこんなことをしているのかと尋ねることができます。 そして、コミュニケーションを通して、痛みを和らげるオプションを見つけます。 または、すべてがそれほど単純ではなく、このプロセスに影響する他の制限がまだたくさんあることを理解しています。

自分自身の仕事について-よくある種の仕事を始めますが、いつも終わらないことがあります。 私の問題は、日単位の時間がたった24時間であり、それを有利に使用するために、自分で何かをする必要がないことです。 1週間何かをするために座っていると、多くのタスクと重要なことが通り過ぎます。

-「私たちはこれを修正する方法を決定します」という言葉に：あなたが修正しなければならなかった錫の最近の例を挙げることができますか？

-最後から、これは不快でした。HAProxyには、トラフィックをアプリケーションに動的にルーティングする内部バランサーがあります。 ニュアンスがあります。これは、アプリケーションに内部検出用のポートがあり、システムで自動的に選択され、アプリケーションのグループ全体に接続されるという事実にあります。

ここでは、異なる機能を担当する2つのアプリケーショングループ間でこのポートを交差させています。 人々は歩き始めました。 最初にサポートが突かれ始め、次に開発者が始められ、何が起こったのかすぐにはわかりませんでした。 ここで、Springは問題の解決に役立ちました。 サービスに関する情報（コミットするリポジトリ、これがすべて収集されたリポジトリ-内部エンドポイント）を返すエンドポイントで、彼はこれを返しました：一度プルすると、1つのグループからアプリケーションの1つのインスタンスに到達し、そこにそれを返しますアプリケーションX（ヘッダーX-Application-idで識別）。 同じエンドポイントをもう一度ジャークすると、バランサーは別のアプリケーションYにルーティングします。誰かが間違って設定したものを見つけるのに時間がかかり、それを間違って設定し、同じリクエストを異なるアプリケーションにルーティングできるようになりました。

-すでにマキシムに同様の質問をしましたが、あなたとエフゲニー・ボリソフはジョーカーのSpring Bootに関する強力なレポートを持っているため、1つの時間枠に収まらないので、測定値を比較したいと思います。 ？ また、Alphaでは新しいバージョンへの移行の問題はどのように解決されますか？

-Spring Bootに関するレポートは、1つのスロットに収まらず、1日のトレーニングに収まらないということではなく、Zhenyaと私は、Spring Cloudにスムーズに流れ込むSpring Bootについて、1日に1回ずつ2つのトレーニングを行いました。

そして、移行について-それは状況に依存します。 もちろん、マイルストーンのバージョンを調査、確認する技術があります。 たとえば、現在gRPCを検討しているなど、現在検討しているテクノロジがあります。 私たちは春に何らかの形でそれを台無しにしようとしています-私はスターターを書いて、それをチェックし、いくつかの大雑把な場所を見つけました。新しいリリースを待つ必要があることに気付きました。 私は新しいリリース、bam、そしてそれらに必要な機能を待っています。 たとえば、検出、負荷分散などに関連する抽象化。

多くの場合、並列プラットフォームに従う必要があります。 最悪の-Node.js。 たとえば、同じgRPCを使用して、ノードの接続の平衡化および復元の実装を調べます。コードには「to do：implement this」という精神でコメントがあり、「いつか誰かが必要になるかもしれません」というメモがあります。 コードから判断すると、人々は原則として誰もがそれを必要とするだろうと一般に考えていませんでした。 私はNodeの専門家ではないので、それを終わらせることすらしませんでした。抽象化することなく、あまり馴染みのないシステムに長い間実装するためです。 そして、たとえサーバーの観点からテクノロジーが私たちを満足させたとしても、異なるプラットフォーム上のクライアントは、信頼できる操作に必要なAPIがないためにそれらを使用できないことがわかります。 常にそのようなことを統治する準備ができており、彼らのアイデアを促進するために、公共の決定に投資する準備ができている人々がいるわけではありません。 内部開発だけでなく、私たちのために「シャープ」な外部コードを実行できる開発者が登場するとき、私たちは常にとても幸せです。 そのような人々のおかげで、ソリューションのメンテナーを待つことができない場合がありますが、ローカル修正を発行するか、公式バージョンで直接修正を取得します。

Springインフラストラクチャの観点から-マイルストーンを見て、まだリリースされていないSpring Boot 2.0とSpring 5.0の両方を調べました。

-答えてくれてありがとう！ そして投稿の継続を準備します。