Често задавани въпроси

Само публичният ключ

Стъпки в терминала

1. Отвори Terminal, Windows Terminal или PowerShell.
2. Изпълни: ssh-keygen -t ed25519 -C "your-email@example.com".
3. Приеми стандартното място или избери сигурен път.
4. Покажи публичния ключ с: cat ~/.ssh/id_ed25519.pub.
5. В Windows PowerShell използвай: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
6. Копирай целия ред ssh-ed25519 в полето SSH public key.

Провери преди поставяне

Публичната част е достатъчна

Стъпки в Windows

1. Отвори PuTTYgen.
2. Избери EdDSA / Ed25519, ако е налично.
3. Използвай RSA 4096 само като резервен вариант.
4. Натисни Generate и движи мишката, докато ключът се създаде.
5. Запази частния ключ на компютъра си.
6. Копирай текста на публичния ключ в полето SSH public key.

Не споделяй тайни данни

Точният hostname е решаващ

Преди DNS промяна

1. Уточнете къде се редактират authoritative DNS записите.
2. Премахнете конфликтни A, AAAA, CNAME, ALIAS, ANAME или redirect записи.
3. Използвайте препоръчания тип за услугата.
4. Изчакайте DNS cache преди финален HTTPS тест.

Безопасно връщане назад

Всеки тип има конкретна роля

При копиране на записи

1. Копирайте име, тип и стойност точно.
2. Не поставяйте CNAME върху име с други записи, ако DNS правилата го забраняват.
3. DKIM сложете под selector от доставчика, DMARC обикновено под _dmarc.
4. CAA променяйте внимателно, защото може да блокира сертификат.

Когато DNS не работи

Работен имейл за целия екип

Преди платена поръчка

1. Потвърдете имейла, ако системата го поиска.
2. Попълнете коректни фактурни данни.
3. Запазете достъпа в фирмен мениджър за пароли.
4. Включете двуфакторна защита, когато е налична.

Достъп без споделяне на парола

Балансът намалява докато услугата работи

Следене на изчерпването

1. Проверявайте видимия баланс след вход.
2. Сравнете дневната цена преди промяна на ресурс.
3. Зареждайте с резерв, а не в последния ден.
4. При спряна услуга вижте показания срок за възможно изтриване.

Проверка на спорен баланс

Оценката не е календарна фактура

При промяна на цена

1. Сравнете старата и новата дневна цена.
2. Отчетете CPU, RAM, диск, архив и платени опции.
3. Приемайте промяната за активна след потвърждение и прилагане.
4. Пазете потвържденията за счетоводство.

Когато сумата изглежда грешна

Чакаща поръчка не е непременно отказ

След връщане от плащане

1. Отворете акаунта си в Cli>_.
2. Проверете статуса и съобщението към плащането.
3. Изчакайте, ако статусът още е чакащ.
4. При проблем изпратете номер на поръчка и видима референция на плащане.

Данни, които не са нужни

Формулярите са за публични стойности

Подготовка преди checkout

1. Изберете разпознаваемо име за екипа.
2. Решете дали ще ползвате собствен домейн.
3. Подгответе публичен SSH ключ, ако е нужен.
4. Проверете размера на диска и ресурсите според приложението.

Ако не знаете дали стойността е чувствителна

Не създавайте нова услуга за промяна

Проверки преди потвърждение

1. Вижте текущите ресурси и ретенции.
2. Проверете новата дневна цена и влиянието върху кредита.
3. Прочетете предупреждение за рестарт или прекъсване.
4. Направете собствен export преди рискова промяна.

Ако промяната не се приложи

Отмяната не винаги е мигновено изтриване

Преди да отмените

1. Направете собствено копие на важните данни.
2. Прочетете точната дата и час за възможно изтриване.
3. Не бъркайте backup ретенция и Offsite Archive със срока за изтриване на услугата.
4. Свържете се с поддръжка преди срока, ако не сте сигурни.

След срока възстановяването не е гарантирано

Backup не е архив за всичко

Какво да има в заявката за възстановяване

1. Име на услуга и номер на поръчка.
2. Приблизителен момент, към който искате връщане.
3. Дали е нужна цяла услуга или конкретна част, ако се поддържа.
4. Видима грешка или контекст без пароли и частни ключове.

Преди потвърждение на възстановяването

Отдалечено архивно копие

Кога да го включите

1. За данни, които трябва да останат отделно от услугата.
2. Когато имате compliance или recovery цел.
3. Когато сте готови да следите цена според обем и дни.
4. Заедно със собствен процес за export при големи данни.

Как се мисли цената

Планирайте според натоварване

Сигнали, че планът е малък

1. Увеличете RAM при OOM, out of memory или постоянно swapване.
2. Увеличете CPU при продължително изчислително натоварване.
3. Увеличете диск преди файловата система да се запълни.
4. След промяна проверете дали първоначалният лимит е изчезнал.

За sizing въпрос

Първо уточнете посоката

Преди поръчка на IP

1. Попитайте дали allowlist е inbound, outbound или и двете.
2. Използвайте DNS имена, ако партньорът ги приема.
3. Отваряйте само нужните портове.
4. Съгласувайте промяната преди production cutover.

Публична IP не значи отворено всичко

Защо портът е висок

Двата възможни SSH пътя

1. При споделен SSH копирайте username, public host и висок порт.
2. Използвайте ssh -p <port> <username>@<public-host>.
3. При закупена публична IP може да има и директен SSH endpoint към тази IP или DNS име.
4. За поддръжка изпратете host, port, username и видима грешка, не частния ключ.

Публичната IP добавя, не заменя автоматично

Точният hostname е решаващ

Преди DNS промяна

1. Уточнете къде се редактират authoritative DNS записите.
2. Премахнете конфликтни A, AAAA, CNAME, ALIAS, ANAME или redirect записи.
3. Използвайте препоръчания тип за услугата.
4. Изчакайте DNS cache преди финален HTTPS тест.

Безопасно връщане назад

Всеки тип има конкретна роля

При копиране на записи

1. Копирайте име, тип и стойност точно.
2. Не поставяйте CNAME върху име с други записи, ако DNS правилата го забраняват.
3. DKIM сложете под selector от доставчика, DMARC обикновено под _dmarc.
4. CAA променяйте внимателно, защото може да блокира сертификат.

Когато DNS не работи

Propagation е cache поведение

При планирана промяна

1. Намалете TTL предварително, ако доставчикът позволява.
2. Не правете случайни повторни промени, докато cache изтича.
3. Тествайте от повече от един resolver.
4. Запишете време на промяната, стара стойност, нова стойност и TTL.

Диагностика на различни отговори

Nextcloud расте извън видимите файлове

Преди увеличение на капацитет

1. Сметнете текущите данни и общите папки.
2. Добавете резерв за версии, кош и previews.
3. Отчетете нови екипи и големи imports.
4. Увеличете storage преди потребителите да ударят лимита.

При sync проблеми

Миграцията не е само clone

Преди cutover

1. Опишете repositories, owners и access groups.
2. Проверете LFS обекти, submodules и protections.
3. След пренос тествайте clone, push, LFS, submodules и CI run.
4. Сменете старите access credentials без да споделяте стойностите им.

Чувствителни данни при миграция

Deliverability започва от домейна

Преди първа кампания

1. Изберете sender домейн или поддомейн и From име.
2. Добавете verification DNS, SPF, DKIM selector и DMARC.
3. Тествайте доставка, bounce или Return-Path и връзките.
4. Проверете unsubscribe и List-Unsubscribe.

Mail достъпите остават извън билета

Auto режимът не е единственият избор

Настройки преди deploy

1. Изберете auto или manual Runtime според framework и build.
2. Изберете PHP 8.2, 8.3 или 8.4 само при поддържан PHP сценарий.
3. Настройте CPU, RAM, диск, backup ретенция и Offsite Archive.
4. След deploy тествайте uploads, cache, logs и видими грешки.

Ако приложението не стартира

Добрият билет има контекст

Безопасно съдържание

1. Опишете стъпката, при която проблемът се появява.
2. За hosting добавете runtime, PHP или език, CPU, RAM, диск, uploads, cache и logs без чувствителни стойности.
3. Маскирайте снимки преди изпращане.
4. Ако се колебаете, попитайте без да изпращате самата стойност.

Какво не се изпраща