როგორ შევქმნათ სტატუს გვერდი: კომპონენტები, ინციდენტები და uptime შემოწმებები

სტატუს გვერდი ერთ ადგილას აჩვენებს მომხმარებლებს, მუშაობს თუ არა თქვენი სერვისი. მის ასაშენებლად გჭირდებათ კომპონენტების სია (ვებსაიტი, API, გადახდები, ელფოსტის გაგზავნა), თითოეული კომპონენტის მიმდინარე სტატუსი, ინციდენტები დროის ანაბეჭდით მოცემული განახლებებით, წარსული ინციდენტების ისტორია და, სურვილისამებრ, გამოწერები, რომ ხალხმა პრობლემის შესახებ შეტყობინება მიიღოს და არ მოუწიოს შემოწმება. თავად გვერდი მარტივია. მთავარი გადაწყვეტილება ისაა, სად მუშაობს: სტატუს გვერდი უნდა რჩებოდეს ხელმისაწვდომი მაშინაც, როცა თქვენი აპლიკაცია გაითიშება, ამიტომ მას არ უნდა ჰქონდეს საერთო ჰოსტინგი, მონაცემთა ბაზა ან დეპლოის მილსადენი იმ სისტემასთან, რომელზეც ის მოგვითხრობს.

რისთვისაა სტატუს გვერდი

რაღაც რომ გაფუჭდება, მომხმარებლებს სამი რამ სურთ იცოდნენ: ეს მხოლოდ მე მემართება თუ ყველას, იციან თუ არა თქვენ ამის შესახებ და როდის გამოსწორდება. სტატუს გვერდი სამივეს პასუხობს დამხმარე მოთხოვნების ნაკადის გარეშე. დროთა განმავლობაში ის ნდობასაც ამყარებს: ხილული ინციდენტების ისტორია გულწრფელი აღწერებით აჩვენებს, როგორ უმკლავდებით პრობლემებს.

ეს არ არის ცვლილებების ჟურნალი. ახალი ფუნქციები ცვლილებების გვერდზე მიდის, გაუმართაობები და ტექნიკური სამუშაოები კი აქ.

რა სჭირდება გვერდს

მონაცემები

კომპონენტის სტატუსები ჩვეულებრივ მოკლე ფიქსირებული სიაა: ნორმალურად მუშაობს, შენელებული მუშაობა, ნაწილობრივი გათიშვა, მთლიანი გათიშვა, ტექნიკური მომსახურება.

გვერდები

• საჯარო სტატუს გვერდი: ზოგადი banner („ყველა სისტემა მუშაობს“ ან ყველაზე უარესი მიმდინარე სტატუსი), თითოეული კომპონენტი თავისი სტატუსით, აქტიური ინციდენტი თავისი განახლებებით, მომავალი ტექნიკური მომსახურება და 90-დღიანი ისტორიის ზოლი, თუ შემოწმების მონაცემები გაქვთ.
• ინციდენტის გვერდი: ერთი ინციდენტის სრული ქრონოლოგია საკუთარი URL-ით, რომ მხარდაჭერამ მასზე მიუთითოს.
• ისტორია: წარსული ინციდენტები თვეების მიხედვით.
• გამოწერა: ელფოსტით რეგისტრაცია დადასტურებით და კომპონენტებზე მორგებული პარამეტრებით.
• ადმინისტრირება: ინციდენტის შექმნა, განახლებების გამოქვეყნება, კომპონენტების სტატუსების შეცვლა, ტექნიკური მომსახურების დაგეგმვა.

უფლებები

საჯარო ხედავს ყველაფერს, რაც გამოქვეყნდა. გამოქვეყნება მხოლოდ თქვენს გუნდს შეუძლია. თუ შესაძლებელია, ადმინისტრატორის შესვლა განაცალკევეთ თქვენი ძირითადი აპლიკაციის ავტორიზაციის სისტემისგან, რომ ავტორიზაციის მომწოდებლის გაუმართაობამ თქვენი სტატუს გვერდიდანაც არ ჩაგკეტოთ.

მთავარი გადაწყვეტილება: დამოუკიდებლობა

სწორედ აქ იშლება ხოლმე ხელნაკეთი სტატუს გვერდები. თუ თქვენი სტატუს გვერდი:

• მუშაობს იმავე სერვერზე ან ჰოსტინგის ანგარიშზე, როგორც თქვენი აპლიკაცია,
• კითხულობს იმავე მონაცემთა ბაზიდან,
• დგას იმავე დომეინის კონფიგურაციის ან CDN-ის უკან,
• ან მას იგივე მილსადენი აქვეყნებს,

მაშინ ბევრი გაუმართაობა მასაც გათიშავს, სწორედ მაშინ, როცა ხალხს ყველაზე მეტად სჭირდება. პრაქტიკული ნაბიჯები:

• ცალკე ჰოსტინგი. სხვა პროექტი ან პროვაიდერი, ვიდრე მთავარი აპლიკაცია.
• საკუთარი ქვედომეინი, მაგალითად status.example.com, DNS-ში ცალკე მითითებული. იხილეთ როგორ მუშაობს დომეინები და DNS.
• საკუთარი მონაცემები. ინციდენტები ინახება სტატუს გვერდის საკუთარ საცავში, არა თქვენი აპლიკაციის მონაცემთა ბაზაში.
• სტატიკური სარეზერვო ვარიანტი. ზოგი გუნდი საჯარო გვერდს სტატიკურად აკეთებს და ყოველი განახლებისას თავიდან აგებს, ასე თითქმის არაფერია გასატეხი.

ხელით განახლება თუ ავტომატური შემოწმება

ხელით (აქედან დაიწყეთ)

გუნდი ინციდენტებს და კომპონენტების სტატუსებს ადმინისტრაციის გვერდიდან ხელით ცვლის. პრაქტიკაში ბევრი სტატუს გვერდი სწორედ ასე მუშაობს, რადგან ადამიანის შეფასება („გადახდები ზოგიერთი ბარათის ტიპზე ნელია“) უფრო სასარგებლოა, ვიდრე ავტომატური წითელი წერტილი.

პრობლემების სწრაფად შესამჩნევად გამოიყენეთ გარე uptime მონიტორი, რომელიც აპლიკაციას დაახლოებით ყოველ წუთს ამოწმებს და ელფოსტით, SMS-ით ან ჩატში გაგაფრთხილებთ. ბევრ მონიტორინგის სერვისს აქვს უფასო გეგმა.

ავტომატური

ავტომატიზაცია ნიშნავს, რომ რაღაც რეგულარულად ამოწმებს თითოეულ კომპონენტს და სტატუსს განაახლებს. ამისთვის საჭიროა კოდი, რომელიც გრაფიკით მუშაობს და თქვენი აპლიკაციის ინფრასტრუქტურის გარეთ. ორი გავრცელებული მიდგომა:

• გარე მონიტორი ეძახის თქვენს სტატუს გვერდს webhook-ის საშუალებით, როცა შემოწმება ვარდება ან აღდგება, და სტატუს გვერდი კომპონენტს განაახლებს.
• დაგეგმილი სამუშაო სტატუს გვერდის საკუთარ ჰოსტინგში პინგავს თითოეულ კომპონენტს და ინახავს შედეგს. სანამ ამას დაეყრდნობით, შეამოწმეთ, როგორ უჭერს მხარს თქვენი ჰოსტინგი დაგეგმილ სამუშაოებს. ვარიანტები აღწერილია ჩვენს გზამკვლევში ფონური სამუშაოების გაშვების შესახებ.

ავტომატური ცვლილებები შეიძლება ზიგზაგებდეს (ზევით, ქვევით, ზევით) ნელ ქსელზე. სტატუსის შეცვლამდე მოითხოვეთ ორი ან სამი წარუმატებელი შემოწმება და დიდი გაუმართაობა ადამიანმა დაადასტუროს, სანამ გამოაცხადებდეთ.

როგორ დავწეროთ ინციდენტის განახლება

• დაწერეთ ადრე. „ვიკვლევთ შესვლის შეცდომების შესახებ მოხსენებებს“ წუთების შემდეგ უკეთესია, ვიდრე სრულყოფილი შეტყობინება ერთი საათის შემდეგ.
• თქვით, რას შეამჩნევენ მომხმარებლები, არა რა გატყდა შიდა სისტემაში.
• აღნიშნეთ შემდეგი განახლების დრო და შეასრულეთ.
• დახურეთ მოკლე შეჯამებით, როცა გადაწყდება: რა მოხდა, რამდენ ხანს გრძელდებოდა და რას ცვლით.

პირველი მუშა მოთხოვნა

ააშენე დამოუკიდებელი სტატუს გვერდი ჩვენი აპლიკაციისთვის Parcelio, რომელიც ცალკე ჰოსტდება status.parcelio.com-ზე. კომპონენტები: ვებსაიტი, Tracking API, Notifications, Payments, თითოეულს აქვს სტატუსი: ნორმალურად მუშაობს, შენელებული მუშაობა, ნაწილობრივი გათიშვა, მთლიანი გათიშვა ან ტექნიკური მომსახურება. საჯარო გვერდი აჩვენებს ზოგად banner-ს ყველაზე უარესი მიმდინარე სტატუსით, თითოეულ კომპონენტს სტატუსით, აქტიურ ინციდენტებს დროის ანაბეჭდით მოცემული განახლებებით, უახლესით ზემოთ, მომავალ ტექნიკურ მომსახურებას და წარსული ინციდენტების სიას თვეების მიხედვით. თითოეულ ინციდენტს აქვს საკუთარი გვერდი. დაამატე პაროლით დაცული ადმინისტრატორის გვერდი ინციდენტების შესაქმნელად (სათაური, ზემოქმედება, დაზარალებული კომპონენტები), განახლებების გამოსაქვეყნებლად (შეტყობინება და სტატუსი: გამოძიება, დადგენილია, მონიტორინგი, გადაჭრილია), კომპონენტების სტატუსების შესაცვლელად და ტექნიკური მომსახურების დასაგეგმად. დაამატე POST /api/check-result endpoint, რომელიც იღებს კომპონენტის სახელს და up/down მნიშვნელობას გარე მონიტორისგან, დაცულია საიდუმლო ტოკენით და კომპონენტს Degraded-ად მონიშნავს მხოლოდ სამი მიმდევრობითი down-ის შემდეგ. ყველაფერი შეინახე ამ აპლიკაციის საკუთარ მონაცემთა ბაზაში. მარტივი, მშვიდი დიზაინი, რომელიც სწრაფად იტვირთება ტელეფონზე.

ასაშენებელი ნაბიჯები

1. საჯარო გვერდი და ადმინისტრატორი ხელით ინციდენტებით. ეს უკვე სამუშაო სტატუს გვერდია.
2. ცალკე ჰოსტინგი და ქვედომეინის მიბმა.
3. ინციდენტის გვერდები და ისტორია.
4. ტექნიკური მომსახურების ფანჯრები.
5. გამოწერები. ორმაგი დადასტურების ელფოსტით რეგისტრაცია და შეტყობინებები ახალ ინციდენტებზე და განახლებებზე. ელფოსტას სჭირდება პროვაიდერი; იხილეთ როგორ გავუგზავნოთ ელფოსტა აპლიკაციიდან.
6. მონიტორის webhook, თუ გინდათ ავტომატური სტატუსის ცვლილებები.
7. სავარჯიშო გაშვება. შექმენით ყალბი ინციდენტი, დაწერეთ განახლებები, გადაჭრეთ, შეამოწმეთ ელფოსტები და შემდეგ წაშალეთ.

გავრცელებული შეცდომები

• ჰოსტინგი აპლიკაციასთან ერთად. ყველაზე გავრცელებული და ყველაზე სერიოზული შეცდომა.
• გვერდი, რომელიც ყოველთვის წერს „ყველა სისტემა მუშაობს“. თუ ის არასდროს აჩვენებს პრობლემებს, მომხმარებლები ენდობა შეწყვეტენ.
• დროის ანაბეჭდებისა და დროის სარტყელის გარეშე. დრო ყოველთვის სარტყელთან ერთად აჩვენეთ.
• დამოკიდებულება აპლიკაციის ძირითად შესვლაზე ადმინისტრატორის გვერდისთვის.
• სიჩუმე განახლებებს შორის. „ცვლილება არ არის, ჯერ კიდევ ვმუშაობთ“ სრულად სწორი განახლებაა.
• ავტომატური სტატუსების ზიგზაგი. ცვლილებამდე მოითხოვეთ განმეორებითი წარუმატებლობა.

როდის არის უკეთესი მზა სტატუს გვერდის სერვისი

მზა სტატუს გვერდის სერვისები სწორედ დამოუკიდებლობის პრობლემისთვისაა შექმნილი: ისინი სხვა ინფრასტრუქტურაზე მუშაობენ, ელფოსტით და SMS-ით ამუშავებენ გამოწერებს და ხშირად შეიცავს მონიტორინგს და ინციდენტების ინსტრუმენტებთან ინტეგრაციას. თუ uptime თქვენი მომსახურების ნაწილია, ან კონტრაქტით ვალდებული ხართ ინციდენტების შესახებ შეატყობინოთ, გამოსადეგია სპეციალიზებული სერვისი. ბევრს აქვს უფასო ან იაფი გეგმა მცირე გუნდებისთვის, ამიტომ ააშენებამდე შეამოწმეთ.

საკუთარი სტატუს გვერდი ღირს, როცა გსურთ სრული კონტროლი დიზაინსა და ფორმულირებაზე, როცა საჭიროებები მარტივია (რამდენიმე კომპონენტი, ხელით განახლებები) ან როცა სტატუს გვერდი თქვენი სხვებისთვის შექმნილი პროდუქტის ნაწილია.

აშენება Mythex-ით

Mythex-ში სტატუს გვერდი შეგიძლიათ აშენოთ როგორც ცალკე პროექტი, განცალკევებული თქვენი ძირითადი აპლიკაციისგან. ეს იძლევა ცალკე ჰოსტინგს და საკუთარ მონაცემთა ბაზას. აღწერეთ ჩატში, შეამოწმეთ ცოცხალ გადახედვაში, შემდეგ გამოაქვეყნეთ და მიაბით ქვედომეინი, მაგალითად status.yourdomain.com (მორგებული დომეინები Pro გეგმაშია). გაითვალისწინეთ, რომ გამოქვეყნებული Mythex აპლიკაციები და მათი მონაცემთა ბაზები უმოქმედობისას ძილში ჩადიან და შემდეგ ვიზიტზე იღვიძებენ, ამიტომ მშვიდი პერიოდის შემდეგ პირველი ჩატვირთვა შეიძლება უფრო ნელი იყოს. მარტივი, მსუბუქი გვერდი ამას ეხმარება.

Mythex არ აღწერს დაგეგმილ სამუშაოებს, ამიტომ ავტომატური შემოწმებებისთვის გამოიყენეთ გარე uptime მონიტორი, რომელიც თქვენი სტატუს გვერდის webhook endpoint-ს ეძახის (იხილეთ webhook-ების რეცეპტი). გამომწერებისთვის ელფოსტის შეტყობინებები თქვენი საკუთარი პროვაიდერით მიდის, გასაღები კი პროექტის საიდუმლოებებში ინახება (ელფოსტის გაგზავნის რეცეპტი).

კითხვები