SPÓJNE TERMINY
Słownik
Krótkie wyjaśnienia terminów z przewodnika. Każdy termin prowadzi do powiązanej lekcji.
Liczba terminów: 46
- Agent
System używający modelu i narzędzi do działania w kierunku celu. Uprawnienia określają możliwe działania.
Przeczytaj lekcję →- AutonomiaAutonomy
Zakres działań wykonywanych przez system bez kolejnej decyzji człowieka. Określ granice według działania i konsekwencji.
Przeczytaj lekcję →- Badania DORADORA research
Badania dostarczania oprogramowania i wyników organizacji. Są odrębne od unijnego rozporządzenia o cyfrowej odporności operacyjnej.
Przeczytaj lekcję →- Budować czy kupićBuild vs buy
Decyzja, które możliwości stworzyć wewnętrznie, a które uzyskać od dostawców. Porównuj odpowiedzialności oraz koszty.
Przeczytaj lekcję →- CI/CD
Ciągła integracja oraz ciągłe dostarczanie lub wdrażanie. Automatyczne procesy budują, sprawdzają i przygotowują lub wydają oprogramowanie według określonych polityk.
Przeczytaj lekcję →- Cloud native
Praktyki powtarzalnego wytwarzania i eksploatacji w dynamicznych środowiskach. Oceniaj automatyzację, stan, odporność i obserwowalność poza pakowaniem w kontenery.
Przeczytaj lekcję →- Diff
Porównanie pokazujące zmiany między wersjami. Przejrzyj rzeczywisty diff, w tym konfigurację i zależności.
Przeczytaj lekcję →- DowódEvidence
Możliwy do sprawdzenia zapis wspierający twierdzenie. Przykłady to wyniki testów, konfiguracja, zatwierdzenia i identyfikatory wydań.
Przeczytaj lekcję →- DPIA
Ocena skutków dla ochrony danych. Ustrukturyzowana ocena ryzyk przetwarzania dla ludzi i środków zaradczych.
Przeczytaj lekcję →- EwaluacjaEvaluation
Określona metoda oceny modelu lub procesu względem reprezentatywnych zadań i kryteriów akceptacji.
Przeczytaj lekcję →- Fabryka oprogramowania AIAI software factory
Model operacyjny łączący pracę nad oprogramowaniem z pomocą AI w całym cyklu życia. Oceniaj odpowiedzialności, zabezpieczenia i dowody poza generowaniem kodu.
Przeczytaj lekcję →- Governance
Prawa decyzyjne, polityki, zabezpieczenia i dowody używane do kierowania pracą oraz przypisywania odpowiedzialności.
Przeczytaj lekcję →- Granica danychData boundary
Określone ograniczenie przepływu danych, dostępu do nich i dozwolonych celów.
Przeczytaj lekcję →- HalucynacjaHallucination
Wygenerowana treść niepoprawna lub niepoparta dowodami, która może wyglądać wiarygodnie. Sprawdzaj twierdzenia o istotnych skutkach względem niezależnych dowodów.
Przeczytaj lekcję →- Infrastruktura jako kodInfrastructure as code
Wersjonowane definicje zasobów i konfiguracji infrastruktury. Plan po review pokazuje proponowane zmiany zasobów.
Przeczytaj lekcję →- KontekstContext
Informacje dostępne modelowi dla bieżącego zadania. Mogą obejmować instrukcje, pliki, rozmowę i wyniki narzędzi.
Przeczytaj lekcję →- Kryteria akceptacjiAcceptance criteria
Warunki, które zmiana musi spełnić. Określ je przed implementacją, aby recenzent mógł ocenić wynik.
Przeczytaj lekcję →- Minimalne uprawnieniaLeast privilege
Przyznawaj tylko uprawnienia potrzebne do określonego zadania. Gdzie to możliwe, ograniczaj zasoby, działania i czas.
Przeczytaj lekcję →- Model frontierFrontier model
Model opisywany jako bliski obecnej granicy możliwości. Etykieta nie gwarantuje poprawności konkretnego zadania.
Przeczytaj lekcję →- Model zagrożeńThreat model
Ustrukturyzowany opis zasobów, granic zaufania, zagrożeń i zabezpieczeń systemu lub procesu.
Przeczytaj lekcję →- Multi-AZ
Wdrożenie w wielu strefach dostępności w regionie AWS. Może ograniczyć narażenie na awarię strefy, zależnie od pełnego projektu.
Przeczytaj lekcję →- Multi-region
Wdrożenie w wielu regionach chmurowych. Określ routing, spójność danych, odzyskiwanie i odpowiedzialności operacyjne dla wymaganego scenariusza awarii.
Przeczytaj lekcję →- ObserwowalnośćObservability
Zdolność badania zachowania systemu przez sygnały, takie jak logi, metryki i ślady. Przydatne sygnały odpowiadają na konkretne pytanie operacyjne.
Przeczytaj lekcję →- Odzyskiwanie po awarii (DR)Disaster recovery (DR)
Przywracanie użytecznej usługi i odtwarzalnych danych po zdarzeniu zakłócającym. Plan obejmuje zależności, decyzje i przetestowane procedury.
Przeczytaj lekcję →- Prompt injection
Próba skłonienia modelu do traktowania niezaufanej treści jako instrukcji. Uprawnienia narzędzi wpływają na możliwe konsekwencje.
Przeczytaj lekcję →- Przegląd koduCode review
Inspekcja proponowanej zmiany kodu. Przed akceptacją recenzent sprawdza zachowanie, zakres, ryzyka i dowody.
Przeczytaj lekcję →- Pull request
Propozycja zmergowania brancha do innego brancha. Gromadzi diff, dyskusję, review i wyniki kontroli.
Przeczytaj lekcję →- RAG
Generowanie wspomagane pobieraniem informacji. System pobiera informacje i przekazuje je modelowi jako kontekst. Pobranie nie czyni treści godną zaufania.
Przeczytaj lekcję →- Rollback
Przywrócenie poprzedniej wersji oprogramowania lub konfiguracji. Zgodność danych może ograniczać bezpieczeństwo rollbacku.
Przeczytaj lekcję →- RPO
Recovery Point Objective: maksymalna akceptowalna utrata danych mierzona czasem. Porównaj użyteczny punkt odzyskiwania z czasem przerwania.
Przeczytaj lekcję →- RTO
Recovery Time Objective: maksymalna akceptowalna przerwa przed powrotem użytecznej usługi. Uwzględnij wykrycie, decyzje, odtworzenie i walidację.
Przeczytaj lekcję →- SamodoskonalenieSelf-improvement
Wykorzystanie informacji zwrotnej do zmiany systemu i potwierdzenia lepszego wyniku. Określ, czy zmienia się kod, konfiguracja, instrukcje, proces czy parametry modelu.
Przeczytaj lekcję →- SamonaprawaSelf-healing
Automatyczne odzyskiwanie po określonej awarii za pomocą zatwierdzonych działań, weryfikacji i warunków zatrzymania. Niekoniecznie usuwa podstawowy defekt oprogramowania.
Przeczytaj lekcję →- SBOM
Wykaz składników oprogramowania. Inwentaryzacja komponentów wspiera analizę, ale nie dowodzi braku podatności.
Przeczytaj lekcję →- SCA
Analiza składu oprogramowania. Analiza zidentyfikowanych zależności, często względem informacji o znanych podatnościach. Pokrycie zależy od narzędzi i skanowanych danych wejściowych.
Przeczytaj lekcję →- SDLC
Cykl życia wytwarzania oprogramowania. Działania potrzebne do określenia, zbudowania, wydania, eksploatacji, zmiany i wycofania oprogramowania.
Przeczytaj lekcję →- SIRT / CSIRT
Zespół reagowania na incydenty bezpieczeństwa. Koordynuje analizę incydentów i reakcję w granicach określonych uprawnień oraz odpowiedzialności organizacyjnych.
Przeczytaj lekcję →- SLO
Cel poziomu usługi. Cel określonej miary zachowania usługi w ustalonym okresie.
Przeczytaj lekcję →- SOC
Centrum operacji bezpieczeństwa. Funkcja zwykle monitorująca sygnały bezpieczeństwa, analizująca alerty i eskalująca podejrzane incydenty. Rzeczywisty zakres trzeba uzgodnić.
Przeczytaj lekcję →- Śledzenie powiązańTraceability
Zdolność powiązania wymagania z implementacją, kontrolami, zatwierdzeniem i wydaną wersją.
Przeczytaj lekcję →- Test regresjiRegression test
Test wykrywający powrót znanego defektu lub niepożądaną zmianę istniejącego zachowania.
Przeczytaj lekcję →- UwierzytelnianieAuthentication
Weryfikacja tożsamości. Sama nie przyznaje uprawnień do rekordu ani działania.
Przeczytaj lekcję →- Vibe coding
Podejście eksploracyjne kierujące generowaniem kodu przez prompty i widoczne zachowanie, często bez sprawdzania każdego wyboru implementacyjnego.
Przeczytaj lekcję →- WdrożenieDeployment
Umieszczenie wersji oprogramowania w środowisku. Wdrożenie i udostępnienie użytkownikom mogą być osobnymi decyzjami.
Przeczytaj lekcję →- Wysoka dostępność (HA)High availability (HA)
Projekt zapewniający dalszą użyteczną usługę mimo określonych awarii komponentów. Sprawdź pełną ścieżkę żądania i pozostałą wydajność.
Przeczytaj lekcję →
Nie znaleziono terminu. Spróbuj innej pisowni.