Bez kategorii

Aktualizacja: problem został już rozwiązany.

Z niezależnych od nas przyczyn system księgowy IFIRMA, którego używamy do fakturowania uległ awarii. Nie są także procesowane poprawnie płatności elektroniczne: kwota za płatność jest pobierana z Państwa konta, ale nie wystawia się faktura i nie przedłuża się subskrypcja. Z uwagi na to prosimy, aby tymczasowo wstrzymać się od realizacji płatności drogą elektroniczną, w szczególności nie ponawiać nieudanych płatności.

Wszystkie zrealizowane płatności zostaną rozliczone po usunięciu awarii systemu księgowego. Za utrudnienia przepraszamy.

Informujemy Państwa, iż w dniu 14.01.2023, od godziny 16.00 do dnia następnego do godziny 06.00 planujemy przerwę konserwacyjną. W tym czasie aplikacja może być całkowicie niedostępna. Niedostępność obejmie także portal naprawiam.online oraz wszystkie interfejsy API.

Aktualizacja 17.11.2022 – problem dostępu do bazy REGON został już rozwiązany

Od kilku godzin obserwujemy problemy z dostępem do bazy REGON. Problem z dostępem ma wpływ na zamawianie subskrypcji dla nowych klientów, oraz klientów po aktualizacji danych. Dodatkowo uzupełnianie danych z bazy REGON podczas dodawania nowych klientów nie działa prawidłowo

W przypadku problemów z zamówieniami subskrypcji prosimy o kontakt za pomocą formularza.

Oszczędzaj pieniądze i środowisko: odbieraj podpisy klientów w formie elektronicznej. Oddajemy Państwu nową funkcjonalność, dzięki której możecie Państwo odbierać pod dokumentami podpisy klientów w formie elektronicznej. Na stronach wydruków znajdziecie nowy przycisk, który uruchomi aplikację do podpisu. Aby odebrać podpis na komputerze można użyć myszki lub tabletu graficznego, na urządzeniach mobilnych z ekranem dotykowym wystarczy palec lub rysik.

Poniżej krótka prezentacja działania:

Po 20 września 2022:

• usuniemy typ Money zastępując do typem Decimal
• wdrożymy rozszerzoną obsługę tzw. complexity dla zapytań GraphQL

Money

Z uwagi na redundancję typów, typ Money zastąpimy typem Decimal. Różnica polega na formacie który będzie zwracany – zamiast łańcucha znaków zwracać będziemy liczbę decymalną, o stałej precyzji, prezentowaną jako typ numeryczny.

Co muszę zrobić?

Zweryfikuj swój kod i upewnij się, że zwracaną przez API wartość poprawnie konwertujesz na pożądany typ oraz używany przez ciebie język podczas konwersji poprawnie zachowuje się podczas rzutowania łańcucha znaków (string) oraz liczby zmiennoprzecinkowej (float) na pożądany typ.

Dodatkowo, jeśli opierasz formatowanie wartości, np ceny, na tym, co uzyskujesz z API będziesz musiał zapewnić samodzielne formatowanie wartości zgodnie z potrzebami. Po 20 września zwracana wartość będzie pozbawiona formatowania typowego dla waluty.

Complexity

Informacje o zagadnieniu complexity znajdą Państwo tutaj: https://github.com/SerwisantOnline/serwisant-api#complexity

Ogólnie: zbyt złożone zapytania do API będą blokowane na etapie parsowania składni zapytania i zwrócą komunikat błędu.

Aby uniknąć tej sytuacji, należy zastosować się do następujących wskazówek:

• dla zapytań pobierających pełne listy encji, np. spis napraw, klientów podawać minimalny zestaw pól (np ID i nazwa wyświetlana)
• pojedyncze encje, które wymagają większej ilości pól (danych) pobierać z filtrem ID i zawsze określać wprost parametr limit: 1

Prosimy o zweryfikowanie Państwa kodu i optymalizację przed 20 września. Zwracamy uwagę szczególnie na drugie zalecenie, ponieważ będzie ono wymagało zmiany w Państwa integracjach.

Nie podajemy teraz wartości granicznej complexity, ponieważ tę ustalimy stosownie do sytuacji, tak, aby zminimalizować wpływ tej zmiany na Państwa. W limit complexity wpadną wyłącznie aplikacje napisane w sposób mocno nieprawidłowy.

Dodatkowo:

• zastrzegamy sobie prawo do wprowadzania przed 20 września trwałego ograniczenia complexity dla indywidualnych integracji, które w sposób abuzywny bedą korzystały z API, powodując zakłócenia w działaniu naszej infrastruktury.
• po 20 września będzie istniała możliwość indywidualnego podniesienia wartości complexity, o ile będzie to miało uzasadnienie z Państwa strony.

Dzisiejsza, około 20 minutowa niedostępność aplikacji Serwisant Online, oraz ponad 60 minutowa niedostępność Naprawiam Online spowodowana była zakłóceniami sieciowymi u dostawcy usługi Cloud, wynikającymi z prac serwisowych po ich stronie. Więcej informacji tutaj.

Update: Dostawca potwierdził rozwiązanie problemu.

Dzień dobry. Od rana notujemy problemy z działaniem API Furgonetki – uniemożliwia to zamawianie przesyłek. Problem leży po stronie operatora API z którym jesteśmy w kontakcie w celu rozwiązania sytuacji.

aktualizacja 17.09.2021 16:30 – usługa wydaje się działać już poprawnie, przy czym nie otrzymaliśmy jeszcze od Furgonetki potwierdzenia dotyczącego eliminacji problemu.

aktualizacja 20.09.2021 11:00 – otrzymaliśmy od Furgonetki potwierdzenie dotyczące rozwiązania problemu.

Pierwszy kwartał 2021 roku przeznaczyliśmy na prace związane z infrastrukturą, tak, aby polepszyć niezawodność dostarczania Państwu najlepszej aplikacji do zarządzania serwisem. Prace prowadzone były w kilku obszarach.

Pierwszym obszarem była zmiana dostawcy usług backupowych. Obecnie korzystamy z usług firmy homecloud.pl oraz jej usług BaaS. Z uwagi na marcową awarię uzyskaliśmy szybką możliwość przetestowania tej usługi „w boju” i bez wahania można powiedzieć, że sprawdziła się w 100%.

Kolejny obszar to migracja systemu składowania plików z rozwiązania self-hosted na rozwiązanie cloud, co zapewnia lepszą skalowalność oraz wyeliminowało słabe punkty związane z hostowanymi samodzielnie serwerami plików. Migracja możliwa była dzięki przeprowadzonej w poprzednim roku aktualizacji frameworka Rails. Obecnie jesteśmy w stanie dostarczyć Państwu nieograniczoną ilość miejsca na pliki w bardzo krótkim czasie.

Innym ważnym obszarem byłą aktualizacja systemów operacyjnych na serwerach, z Debian 8 na Ubuntu 18.04.5 LTS. Migracja objęła wszystkie używane przez nas serwery i wymagała utworzenia dla każdego z nich dedykowanych scenariuszy instalacji w Ansible. Posiadanie tego typu scenariuszy umożliwia nam szybkie dostarczanie dodatkowych serwerów o identycznej konfiguracji, w celu skalowania wydajnościowego lub np procedury DRP.

Ostatnim obszarem byłą optymalizacja redundancji usług: dla usług związanych z bazą danych SQL, pamięcią podręczną oraz wyszukiwaniem wyeliminowaliśmy mało efektywne metody wykrywania awarii i reagowania na nie na rzecz rozwiązań dedykowanych, opartych specjalnym na oprogramowaniu. Te operacje dodatkowo pozwalają na zwiększanie wydajności tych usług poprzez balansowanie ruchu na wielu węzłach. Obecnie rozwiązanie to działa dla mechanizmu wyszukiwania. Będziemy je testowali i wdrażali także dla baz danych SQL.

Dodatkowo, co zostało podyktowane siłą wyższą przenieśliśmy całą aplikację z serwerowni w Sztrasburga (FR) do Warszawy (PL).

W tej informacji chciałbym podsumować incydent z 10 marca 2021 związany z niedostępnością aplikacji.

Powodem niedostępności był czynnik losowy w postaci pożaru w serwerowni OVH, firmy będącej naszym dostawcą infrastruktury. Pożar objął jeden z obiektów, niszcząc go bezpowrotnie, równocześnie powodując szereg skutków ubocznych, w wyniku których unieruchomiony został cały region serwerowy SBG.

Niedostępność aplikacji rozpoczęła się około godziny 01:09.

Z uwagi na to, że informacje o skali problemu po stronie OVH były niejednoznaczne, czekaliśmy z decyzją o uruchomieniu DRP do godziny 14.30.

Procedura DRP polegała odtworzeniu pełnej, redundantnej infrastruktury, konfiguracji i instalacji oprogramowania na nowych serwerach, przywrócenia danych z kopii zapasowych oraz uruchomieniu aplikacji.

Zdecydowaliśmy się na odtworzenie infrastruktury w polskim regionie OVH (region WAW1). Napotkaliśmy tu na niezależnie od nas problemy będące efektami ubocznymi awarii w SBG: przeciążenie systemów OVH, problemy z alokacją sieci prywatnych. Ostatecznie uruchomiliśmy 14 serwerów i zabezpieczyliśmy je firewallem.

Na etapie konfiguracji i instalacji oprogramowania użyliśmy konfiguracji z Ansible, przy czym z uwagi na dług technologiczny po naszej nie posiadaliśmy stosownej konfiguracji dla serwerów SQL. Konfiguracja ta powstała w trakcie operacji DRP, co nieznacznie wydłużyło proces.

Odtworzenie danych przebiegło bez problemu. Ostatnia kopia bazy danych w systemie backupu wykonana została 09.03.2021 o godzinie 20:40, a więc już po zakończeniu głównej aktywności w aplikacji, na 5h przed incydentem. Kopia załączników plikowych była jeszcze świeższa: wykonana 10.03.2021 o godzinie 00.20. Po odtworzeniu danych zabezpieczyliśmy je w systemie kopii zapasowych.

10.03.2021 o godzinie 20:45, a więc 20 godzin po wystąpieniu awarii uruchomiliśmy ponownie aplikację w nowej serwerowni.

W najbliższą sobotę, 13.03.2021 po 15.00 oraz w niedziele 14.03.2021 będziemy prowadzili prace serwisowe, które mogą skutkować przejściową niedostępnością aplikacji. W trakcie prac będziemy optymalizowali infrastrukturę uruchomioną w ramach DRP. W poniedziałek przygotujemy Państwu podsumowanie incydentu związanego z niedostępnością serwisu.