FTKONF-023
Amikor bocsánatot kell kérned az ügyféltől
Helyzet
„Mit tegyek, ha törő változást vezettem be egy REST API-ban, és valós következményei lettek?” · „What to do when you introduced breaking changes in a REST API, consequences were real…?” · szerző: user27021198 · CC BY-SA
Egy külsős fejlesztő (tanácsadó) egy állami megbízónál módosított egy rendszert: kivett belőle valamit, amiről azt hitte, senki sem használja. Bemutatta a változást az egyik csapatnak, akik átálltak rá, de egy másik rendszer is használta az adatot, az ő tudta nélkül. Eredmény: több száz embernek nem ment ki a havi kifizetése, és ez csak egy hónappal később derült ki. Most rendeznie kell a megbízóval, a saját csapatvezetőjével és a megbízás-adó cégével is.
A forrásposzt teljes szövege (magyarul és angolul)
Az eredeti Stack Exchange-kérdés hű magyar fordítása · szerző: user27021198 · The Workplace, q198935 · CC BY-SA.
Kérdés: Mit tegyek, ha törő változtatásokat (breaking changes) vezettem be egy REST API-ban, a következmények valósak voltak, és csak utólag tudtam meg róla?
Külsős IT-tanácsadó vagyok (Java-fejlesztő), aki egy állami tulajdonú ügynökségnek (az ügyfélnek) dolgozom, amely havi kifizetésekkel foglalkozik (pl. juttatások, nyugdíjak stb.). A csapatom nem közvetlenül a kifizetésekkel foglalkozó rendszereket tartja karban, hanem egyfajta „ügyféladatot" kezelünk, amelyet az említett kifizetési rendszerek használnak. Épp egy hosszú szabadság előtt változtattam egy REST API válaszán, amelyet az A-Csapatnak kellett volna használnia egy olyan rendszerhez, amelyhez az API-t eredetileg fejlesztették. Ez a változtatás eljutott a produkcióba, regressziók nélkül stb. Az A-Csapat tudott róla, bemutattam a változtatásaimat egy demó-ülésen, ők hozzáigazították a rendszerüket stb. Azért változtattam meg az API válaszát, mert az tartalmazott néhány hibás adatot, és ezt a hibás adatot közvetlenül eltávolítottam, anélkül, hogy új verziót biztosítottam volna az API-hoz. De amikor visszajöttem a szabadságról, és átnéztem az e-mailjeimet, megtudtam, hogy egy másik kifizetési rendszer, amely ezt a REST API-t használta (az én vagy a csapatom tudta nélkül), nem találta meg a benne keresett információt a frissített API válaszában a változtatásomat követően, és több száz ember, aki kifizetésre számított, többé nem kapta meg. Időközben a másik rendszerért felelős B-Csapat hozzáigazította a kódját, és ezek az emberek végül megkapják a pénzüket. Amikor visszatértem a munkába, senki nem említett semmit erről. Nagyjából egy hónappal azután fedezték fel ezt a problémát, hogy produkcióba került, innen a több száz érintett ember... Most már belátom a hibáimat. A legfontosabb az volt, hogy nem új, különálló API-verzióként vezettem be a változtatásokat, hanem közvetlenül. Túl magabiztos voltam a hibás adat eltávolításában, mert azt hittem, senki sem használja, hiszen eleve hibás volt. Ugyanilyen fontos hiba volt, hogy nem kommunikáltam globálisan, egy globális csatornán, hogy változás lesz ebben a REST API-ban. Nem tartottam szükségesnek, mert ezt az API-t csak egyetlen projektre tervezték, és kommunikáltam velük, és tartottam egy demó-ülést. Hogyan kezeljem ezt szakszerűen a csapatunk ügynökségnél lévő Koordinátorával, az architekttel, a csapatom vezető elemzőjével és a céggel, amellyel a szerződésem van, a menedzseremmel? Hogyan vállaljak felelősséget szakszerű módon? Először a koordinátorhoz és/vagy az architekthez (ezek kereszt-csapat szerepkörök) forduljak? Vagy először a csapatom vezető elemzőjéhez? Frissítsem az önéletrajzomat, és kezdjek új állást keresni? Eddig ezt tettem: Bocsánatot kértem a B-Csapattól, írásban. Átnéztem a változtatásokat, amiket csináltam, és a B-Csapat által küldött példákat, hogy lássam, valóban azt használták-e, ami eleve hibás adatnak tűnt. Átnéztem a jegy (ticket) megjegyzéseit, és ellenőriztem, volt-e bármilyen módja annak, hogy magamtól tudjam, más rendszerek is használják-e ezt az API-t. Köszönöm!
Original Stack Exchange question · author: user27021198 · The Workplace, q198935 · CC BY-SA.
What to do when you introduced breaking changes in a rest api, consequences were real and you found out about it after the fact?
I’m an external IT Consultant (a Java developer) working for a state-owned agency (the client) that deals with monthly payments (f.e. allowances, pensions etc). My team doesn’t maintain systems that deal with payments directly, instead we handle a sort of “customer data” that is used by the said payment systems. Just before going on a long holiday, I did a change in the response of a REST API that was supposed to be used by Team A for a system for which the API was initially developed. This change made it to production, no regressions etc. Team A was aware, I presented my changes in a demo session, they adapted their system etc. I changed the response of the API because it contained some incorrect data and I removed this incorrect data directly, without providing a new version for the API. But when I got back from my holiday and sieved through my e-mails I found out that another payment system that used this REST API (without my, or my team’s knowledge) couldn’t find the information it was supposed to find in the response of the updated API following my change, and hundreds of people who were expecting a payment, didn’t receive it anymore. In the meantime the Team B responsible for this other system adapted their code and these people will get their money eventually. When I resumed working nobody mentioned anything about this. They discovered this issue roughly one month after it was deployed in production, hence the hundreds of people impacted... I realize now my mistakes. The most important one was not to introduce the changes as a new, separate API version, but directly. I was too confident in removing incorrect data, because I thought nobody was using it because it was incorrect to begin with. Equally important mistake was not to globally communicate on a global channel that there was going to be a change in this REST API. I didn’t deem it necessary because this API was designed for one project only, and I communicated and had demo session with them. How should I handle this, in a professional manner, with our team’s Coordinator at the agency, the architect, my team’s lead analyst and my manager from the company with which I have the contract ? How should I take responsibility in a professional way ? Should I approach the coordinator and/or the architect (these are cross-team roles) first ? Or my team’s lead analyst first? Should I brush up my CV and start looking for a new job ? This is what I did so far: I apologized to Team B, in writing. I reviewed the changes I did, and the examples sent by the Team B, to see if they indeed used what seemed to be incorrect data in the first place. I reviewed the comments of the ticket and checked if there was any way for me to know, on my own, if other systems used this API. Thanks!
A közösség legjobbnak ítélt válasza
Bart van Ingen Schenau (7) · CC BY-SA
The professional way to deal with this error is to tell your architect and lead analyst about what happened. This should not be in the form of an apology, but a fact-based narrative of a failure in the processes … then start looking together at how the processes can be improved so a repeat can be avoided.
Magyar összefoglaló: a működő bocsánatkérés nem szóvirág, hanem tényszerű elismerés + jóvátétel + a folyamat javítása, hogy ne ismétlődjön. A „sajnálom, ha" eltol; a „sajnálom, hogy" felelősséget vállal.
Valós forrás: „What to do when you introduced breaking changes in a REST API, consequences were real…?” · szerző: user27021198 · Stack Exchange / The Workplace (q198935) · CC BY-SA · magyar fordítás, anonimizálva. Az eredeti poszt →