Seit dreizehn Jahren suchen wir nach Möglichkeiten, die Entwicklung so zu skalieren, dass alles zuverlässig funktioniert, wenn es wächst, und gleichzeitig werden neue Funktionen schnell veröffentlicht. Früher schien es wichtig, Spalten in einer Datenbank einfach umzubenennen. Jetzt musste ich unterwegs die gesamte Architektur ändern.
Dies ist der dritte jährliche Entwicklungsbeitrag für Black Friday, die Spitzenwoche. Warum denken wir endlich, dass wir großartig sind? was sie dafür getan haben; warum wir auf Schwierigkeiten gestoßen sind und was wir als nächstes vorhaben.
Zusammenfassung: Zwei Jahre Arbeit aus gutem Grund
Zum fünften Mal in Folge verdoppelt sich die Belastung von Mindbox jährlich ungefähr. Im November 2020 haben wir 8,75 Milliarden API-Anfragen bearbeitet, verglichen mit 4,48 Milliarden im Vorjahr. Der Spitzenwert liegt bei 400.000 Anfragen pro Minute. 1,64 Milliarden E-Mails und 440 Millionen mobile Benachrichtigungen gesendet. Vor einem Jahr gab es 1,1 Milliarden E-Mails, aber es gab fast keine Push-Nachrichten.
Dynamik der Anzahl der Mailings pro Woche am Black Friday:
Nach unseren Daten ist dies in Bezug auf die Auslastung von Datenbanken mit dem hh.ru-Auslastungsgrad für API-Anforderungen vergleichbar - mit Avito. Etwa ein Drittel von Yandex-Taxi auf Anfrage pro Minute.
In den Jahren 2018 und 2019Im Laufe der Jahre haben wir uns schlecht damit befasst: Kunden haben unter Ablehnungen gelitten. Ende 2018 hoffte ich auf schnelle Verbesserungen und erwartete eine Business-Roadmap, die bisher nur zur Hälfte fertiggestellt wurde. Im Jahr 2019 beschloss ich, über die Roadmap zu schweigen, da sich die Zuverlässigkeit verschlechterte, die Ausfälle im September begannen und sich am Schwarzen Freitag trotz des großen Arbeitsaufwands wiederholten.
Heute können wir schließen: Wir haben gelernt, mit Wachstum umzugehen. Der schwarze Freitag 2020 verlief ohne Zwischenfälle, von denen mehr als ein Kunde betroffen war. Es gab zwei kurzfristige Teilausfälle aufgrund einer externen Infrastruktur, die nicht gegen das SLA verstießen. Leider gab es Beschwerden von mehreren der größten Kunden, aber dies sind einzelne Geschichten, die wir verstehen und an denen wir arbeiten.
Darüber hinaus zeigen die Daten und subjektiven Nutzerbewertungen einen langfristigen Trend zur Steigerung der Entwicklungsqualität. Die Anzahl der Fehler - kritische Fehler, Ausfälle und Fälle unbefriedigender Leistung - wird reduziert.
Die Grafik zeigt Verstöße gegen das interne SLA (strenger als das externe), die wir in diesem Jahr zusätzlich noch verschärft haben:
Anzahl der internen SLA-Verstöße eines durchschnittlichen Kunden
Wir haben es geschafft, die Entwicklung in zwei Jahren vollständig neu zu erfinden und sind mit einer durchschnittlichen Wachstumsrate von 40% weiter gewachsen pro Jahr (2019 - 431 Millionen, 2020 - 618 Millionen) und Veröffentlichung neuer Funktionen. Gefühle - darüber, wie man den Motor eines Autos bei voller Geschwindigkeit wechselt.
Was wurde in zwei Jahren getan:
- (LESS) , , .
- 50% , ( ) .
- SRE. SRE .
- , , .
- SLA .
- «-», .
Dies ist alles andere als geplant. Wir erhöhen weiterhin die für die Qualität bereitgestellten Ressourcen. Wir erwarten weitere Qualitätsverbesserungen und eine schnellere Veröffentlichung neuer Funktionen im Jahr 2021 und darüber hinaus.
Übrigens schreiben wir regelmäßig über Produktaktualisierungen und pflegen eine Statusseite mit einer Historie von Vorfällen .
Die Ursprünge der Schwierigkeiten: 2008-2018
Mindbox ist ein Produkt mit komplexer Geschäftslogik. Seit 2008 entwickeln wir einen Service für große Unternehmen mit einem Anteil an den Entwicklungskosten von über 30%. Aus architektonischer Sicht war es eine traditionelle monolithische Anwendung, aber von sehr hoher Qualität: Jeden Tag haben wir mehrere Monolith-Updates veröffentlicht und veröffentlichen sie immer noch.
Im Jahr 2014 haben wir uns aufgrund des Marktes einem massensichereren Segment zugewandt, einschließlich E-Commerce und Einzelhandel. Dies erforderte eine Investition in Kundenservice, Vertrieb und Marketing.
Das Unternehmen hat nie externe Investitionen angezogen, es hat sich immer aus eigenem Gewinn entwickelt. Darüber hinaus hatten wir 2017, sechs Monate nachdem ich CEO geworden war, einen Geldmangel, Angst und erhöhte meine Rentabilität übermäßig. All dies führte 2018-2019 zu einer Reduzierung der Entwicklungskosten auf 24% des Umsatzes.
Gleichzeitig mussten viele Funktionen freigegeben werden, die von Neukunden benötigt wurden - mit einem raschen Anstieg der Auslastung und der Anzahl der Kunden. Wir haben den Rückstand des ursprünglichen Produkts und der ursprünglichen Architektur sowie die Dezentralisierung bewältigt - die Bildung autonomer Produktteams.
Leider konnte das technische Know-how solcher Teams nicht mit dem Wachstum des Unternehmens Schritt halten, was durch die Grenzen des Möglichen in der monolithischen Architektur weiter verschärft wurde. Die technischen Schulden häuften sich, die verwendete Technologie war veraltet und die Gehälter lagen unter dem Markt. Die Einstellung von Ingenieuren ist trotz der herausfordernden Herausforderungen und der einzigartigen Unternehmenskultur immer schwieriger geworden. Bis 2018 hatte sich die Anzahl der Kunden verzehnfacht, der Erfolg des Produkts sowie die Probleme in Bezug auf Zuverlässigkeit und Entwicklung im Allgemeinen wurden offensichtlich.
Welche Maßnahmen haben wir ergriffen?
Prozesse und Ressourcen
Die erste Hypothese war die Zentralisierung: 2019 wurde WENIGER eingeführt - dies ist der Fall, wenn mehrere Teams gleichzeitig an einem Projekt arbeiten. Wir haben begonnen, gemeinsam Epen zu entwerfen und zuverlässig zu arbeiten. Es ist uns gelungen, die Vorhersehbarkeit zu verbessern und nützliche Entwurfspraktiken zu finden. Nach einem Jahr wurde jedoch die Ineffizienz des Prozesses offensichtlich: Demotivation und reduzierte Verantwortung der Teams aufgrund des Mangels an "ihren" Merkmalen, hohe Verwaltungskosten, die niemand gerne tat.
Über ein Jahr kollaborativen Designs entstand die Vision einer dezentralen Architektur, die es jedem Team ermöglicht, für isolierte Mikrodienste verantwortlich zu sein und weiterhin ein einziges Produkt an Kunden zu liefern. Zusammen mit der Vision zeigten sich Rückstände von Aufgaben und es wurde klar, dass es notwendig war, mit engagierten Spezialisten an der Infrastruktur zu arbeiten, ohne sie mit einer Geschäfts-Roadmap zu unterbrechen.
Wir haben vereinbart, 30% der Mittel für technische Schulden fortlaufend bereitzustellen. Das erste Infrastruktur-Team wurde gebildet, und autonome Teams wurden erneut zugewiesen. Gleichzeitig wurde eine Reihe zentraler Prozesse für die Zusammenarbeit beibehalten, die in erster Linie auf die Aufrechterhaltung der Qualität abzielen:
- Design,
- Fehleranalyse,
- Modellierung der Eisenlast,
- Demo- und Synchronisierungsstatus.
Die Architekten und Teams wurden für Zuverlässigkeitsmetriken und Serverkostenvorhersagen verantwortlich gemacht. Zusätzlich haben wir in jedem Team 30% für technische Schulden und Fehler bereitgestellt, während wir auf die Geschäftskontinuität gewartet haben.
Im Jahr 2020 haben sich die Prozesse beruhigt: Wir haben ein zweites Infrastruktur-Team gebildet und die Lieferung wurde angepasst. Der Anteil der Ressourcen für Geschäftsaufgaben begann langsam von einem Tiefpunkt von etwa 50% zu wachsen, und der Anteil der Fehler begann abzunehmen:
Verteilung der Entwicklungsressourcen nach Aufgaben. Die Grafik ist nicht sehr informativ, da erst vor relativ kurzer Zeit eine zuverlässige Metrik erstellt wurde, die jedoch durch Eindrücke aus der
Praxis unterstützt wird. In dieser Zeit haben wir gelernt, wie man SREs anstellt und integriert, sie von DevOps und der Büro-IT trennt, Dienstprozesse formuliert und die Rolle beschreibt.
Der Mangel an Ingenieuren wurde auf zwei Arten verringert:
- Wir haben eine Entwicklungsschule gegründet, die jährlich 8-12 Nachwuchsentwickler ausbildet. Dies sind Entwickler, die Erfahrung mit unserem Stack haben und auf deren Fähigkeiten wir vertrauen. Heute hat die Schule 2 Teams mit 4 Auszubildenden.
- Wir haben die Lohnsumme für die Entwicklung systematisch erhöht, da die Geschäftsergebnisse dies zuließen. Das durchschnittliche Gehalt in der Entwicklung ist von 120.000 Rubel im Jahr 2015 auf über 170 Rubel Ende 2020 gestiegen und wächst weiter. Dies ermöglichte es uns, mehrere neue starke Senioren und technische Leiter einzustellen. Der Anteil der Entwicklungskosten stieg auf 28% und die Zahl der Menschen stieg von 27 auf 64.
Metriken, Metriken und automatische Metriken
In unserer Kultur ist es üblich, Daten zu verwalten, nicht persönliche Meinungen. Effektive Metriken sind möglicherweise eine der schwierigen Fragen, auf die moderne Entwicklungsmanagementmethoden keine direkte Antwort geben.
Wir haben zunächst vier Metriken aus dem Accelerate- Buch automatisiert und die Lieferpipeline beschleunigt. Dies hatte keine unmittelbaren offensichtlichen Auswirkungen. Der Erfahrungsaustausch mit hh.ru und Yandex-Cloud führte uns jedoch zur Automatisierung der SLA-Verstoßmetrik und zur automatischen Feststellung von Fehlern. Hier haben wir den Nutzen und die Verbindung mit den unternommenen Anstrengungen deutlich gespürt. Das Diagramm dieser Metrik mit einem Trend befindet sich am Anfang des Beitrags.
Diskret, aber ich denke, wir sind eines der wenigen Unternehmen auf der Welt, das über eine API für Kunden verfügt, mit der Sie die Verfügbarkeit von Plattformkomponenten in Echtzeit abrufen können.
Die oben beschriebene Metrik für den Anteil von Fehlern und technischen Schulden im Team scheint ebenfalls nützlich zu sein. Darüber hinaus prüfen wir, wie die Teams die für den Sprint gegebenen Versprechen erfüllen und die Entwickler die Fristen für tägliche und wöchentliche Aufgaben einhalten.
Schließlich zeigen anonyme vierteljährliche Umfragen (die Texte haben sich seitdem verbessert, aber das Wesentliche der Umfrage hat sich nicht geändert) und eine hohe Bewertung von Habr-Karer zeigen eine Abnahme des Entwicklungsunglücks. Dies betrifft die Bewertung ihres Einkommens im Verhältnis zum Markt, zu Raffinerien und zum eNPS (Daten für bisher nur zwei Viertel).
Entwickler Income -
Umfrage:
Entwickler Overhaul Umfrage : ENPS Entwickler:
Auf einer Skala von 1 bis 10, wie wahrscheinlich sind Sie Mindbox als Ort zum Arbeiten empfehlen?
Last but not least Technologie
All dies ermöglichte es, das Umschreiben eines monolithischen Produkts - mehr als 2 Millionen Codezeilen unter IIS + ASP.NET + NLB / Windows-Dienst / MS SQL - gleichzeitig in alle Richtungen zu organisieren:
- Microservice API und Backend, wenn eine Clientanforderung an API Gateway von mehreren Microservices transparent verarbeitet wird, einschließlich synchroner Anforderungen (Saga-Muster).
- Mikrofront-Ende, bei dem die Schnittstellenabschnitte von den Backend-SPA-Anwendungen getrennt sind, die in ihren eigenen Repositorys mit eigener Layout-Pipeline gehostet werden können.
- Übertragung von mandantenfähigen Microservices von MS SQL auf verteilte skalierbare Speicher: Cassandra, lickhouse. Kafka statt RabbitMQ.
- Übertragung der Anwendung auf .NET Core, Linux und teilweise Übertragung auf Managed Kubernetes "Yandex-Clouds". Sofort die Einführung moderner SRE- und DevOps-Technologien: OctopusDeploy + Helm, Prometheus, Grafana, Graylog + Sentry, Amixr.IO.
Vielleicht sind wir einer der am stärksten ausgelasteten Kunden von Yandex Cloud, daher sprach Nikita Prudnikov über unsere Implementierung und die Überwindung der Schwierigkeiten von CTO mit Yandex bei Yandex Scale 2020 .
In unserem Artikel am Black Friday können Sie anhand eines Beispiels für eine Mailinglistenkomponente, die im letzten Jahr nicht und in diesem Fall nicht funktioniert hat, mehr über unsere wichtigsten Skalierungsansätze erfahren.
Weiterentwicklungspläne
Trotz der erzielten Ergebnisse muss ich sagen, dass weniger als die Hälfte der geplanten Maßnahmen durchgeführt wurde. Voraus:
- Steigern Sie weiterhin das Entwicklereinkommen und stellen Sie die besten Senior- und Tech-Leads ein
- Das dritte Team der Entwicklungsschule, mit dem bis zu 12 Entwickler pro Jahr eingestellt werden können
- Fortsetzung der Übersetzung der Anwendung in .NET, k8s und Yandex-Cloud, automatische Skalierung, blaugrünes Layout mit sofortigem Rollback
- Übergang zur automatischen Ermittlung von Vorfällen auf der Statusseite, um falsche SLA-Positive zu beseitigen
- Migration auf .NET 5, EF.Core und PostgreSQL (und Entwickler auf neue MacBooks)
- Auswahl einiger weiterer großformatiger Stücke aus dem Monolithen
Motivierter Drang, die .NET-Entwickler Tehlidov und SRE-Spezialisten zu vergrößern, um auf unsere Aufgabe gegenüber hh.ru zu reagieren . Es wird interessant sein, Sie können auf dem Markt einzigartige Erfahrungen sammeln und Dinge tun.
Roadmap-Plattformen im Jahr 2021
Wir fühlten ein solides Fundament unter unseren Füßen, das uns hoffen lässt, dass wir die Versprechen auf der Business Roadmap wieder erfüllen können. Wir probieren zum ersten Mal ein Jahr lang die Prozesse der dezentralen Planung aus, aber ich werde mir rücksichtslos erlauben, öffentliche Erwartungen zu formulieren.
Dieses Jahr werden wir die Plattform erweitern:
- Szenariokonstruktor .
- Speichern und Melden anonymer Bestellungen
- Schnellere Berichte in der Benutzeroberfläche ( wie in unserem Kurs )
- Integration mit BI
- Neues Modul für mobile Push-Benachrichtigungen, einschließlich eines neuen SDK
- Die Möglichkeit, Entitäten unter Berücksichtigung von Abhängigkeiten schnell zu löschen
- Mehr ML-Algorithmen und viele Qualitätsverbesserungen gegenüber bestehenden
- Weitere Seiten in einem neuen Design mit verbesserter Reaktionsfähigkeit der Benutzeroberfläche
- Vereinfachte Anpassung von Standardintegrationen und Mechanik
Die Pläne für 2022 sind ehrgeiziger, aber ich hoffe, dass ich in einem Jahr darüber schreiben kann, wenn der Optimismus gerechtfertigt ist.
Vielen Dank
Wie die Erfolgsgeschichten der Kunden ist auch diese das Verdienst bestimmter Personen, denen ich meinen Dank aussprechen möchte:
Nikita Prudnikov, CTO, für die Vision, die Beständigkeit und das systematische Zusammendrücken.
Roman Ivonin, leitender Architekt, für Geduld, Teambildung, breite Verantwortung, informelle Führung und schlaflose Nächte.
Igor Kudrin, CIO, für die Grundlage von SRE-Fachwissen, Vision und Rettung von allem, wenn niemand weiß wie.
Rostislav, Leonid, Dmitry, Mitya, Ilya, zwei Artyom, Alexei, Sergei, Nikolai, Ivan, Slava, Zhenya und andere fürsorgliche Entwickler, Produkte, technische Leiter und SRE, die alles Wirklichkeit werden ließen. Entschuldigung, wenn ich niemanden erwähnt habe.
Besonderer Dank geht an die Kunden, die trotz des Scheiterns durchgehalten haben und die Gelegenheit zur Verbesserung gegeben haben. Wir werden alle Anstrengungen unternehmen, um es besser zu machen.