Caminhos de serviço, dependências e modos degradados

Semana 1, dia 3. Percorra o ensino e o marco resolvido antes de tentar os exercícios indicados. Compare o seu artefato com a resolução final só depois.

1.2b Caminhos essenciais de serviço e modos degradados

Um componente em execução não é um serviço de negócio entregue

Um site de biblioteca pode responder enquanto o sistema de reserva subjacente não consegue exibir as salas atuais nem aceitar uma reserva. Um monitor de cópia pode relatar um trabalho concluído enquanto ninguém mostrou que a cópia resultante restaura uma agenda correta. Uma central de atendimento pode ainda receber o pedido de um frequentador enquanto a reserva feita por computador não pode ser aceita. As três situações ilustram o mesmo problema de preparação: a organização pode dizer com verdade que alguma tecnologia permanece operacional sem estabelecer que o resultado prometido ao usuário está disponível.

O capítulo 01 existente começa corretamente com um mapa de serviço e um contrato D1 de prontidão de evidência. Um mapa de serviço diz a quem responde quais componentes e donos importam. D1 pergunta se observações úteis poderiam ser obtidas sob autoridade, inclusive semântica da fonte e evidência ausente. É necessária uma terceira pergunta: quais funções exatas, voltadas ao usuário, uma falha de componente afetaria? Respondê-la exige um modelo de dependência específico da função, em vez de tratar todo componente como globalmente saudável ou globalmente fatal.

Uma função de serviço é uma operação específica com um resultado útil definido. Uma dependência técnica é algo exigido para realizar essa operação na arquitetura e no modo declarados. Um modo degradado é um estado operacional deliberadamente mais estreito, no qual algumas atividades continuam, mas outros compromissos de serviço não podem ser feitos com honestidade.

Essas distinções são consistentes com a ênfase em dependências de serviço e recuperação de função de negócio no NIST SP 800-184, Guide for Cybersecurity Event Recovery e com a preparação de resposta atenta ao risco no NIST SP 800-61 Revision 3. Essas publicações do NIST não especificam as rotas internas da Harbor Library; PATH1 é material original de raciocínio de sala.

Comece pela promessa feita a um frequentador

Imagine cinco funções distinguíveis de um serviço hipotético de reserva: uma página informativa que responde, uma lista atual de salas sendo exibida, um membro autorizado da equipe editando uma reserva, um empregado da recepção registrando um pedido pendente, e um trabalho novo de cópia obtendo os dados de origem.

Os resultados não são intercambiáveis. Uma resposta bem-sucedida de página informativa diz pouco sobre a exatidão da reserva. Uma edição de equipe aceita é uma mudança de estado de negócio, que pode exigir autorização e armazenamento durável. Um recibo de pedido manual não é aceitação de uma reserva. O acesso de um trabalho de cópia a uma base de dados não é uma restauração testada nem um retorno aceito ao serviço.

Uma frase fraca de prontidão diz “a aplicação está disponível”. Uma frase mais útil diz “a função autorizada de edição pela equipe produziu a mudança esperada na reserva pretendida, e um revisor conferiu o estado autoritativo resultante num teste controlado”. A segunda frase tem um resultado testável e um escopo declarado.

Na profundidade do curso rápido, quem estuda deve identificar a unidade de sucesso antes de selecionar um teste. A pergunta é sobre alcançar uma página, ver uma sala atual, fazer uma reserva, recolher um pedido pendente ou produzir um objeto de cópia? Cada unidade precisa de uma resposta diferente e pode ter dependências técnicas diferentes.

Este enquadramento também melhora a comunicação do incidente. O responsável pelo serviço pode aprovar legitimamente um contorno limitado de recepção de pedidos, mas a equipe não deve anunciar que salas estão confirmadas enquanto as escritas estão indisponíveis. Um aviso honesto de serviço degradado deve explicar o que o usuário pode fazer, o que permanece pendente e o que precisa ocorrer antes de a confirmação ser possível.

Expresse premissas de caminho como uma tabela pequena de dependências

O modelo de ensino PATH1 usa componentes nomeados web, identity, database, helpdesk e backup. Essas categorias se parecem com o mapa de serviço, mas as conexões específicas são inventadas. Os registros canônicos R1–R8 não confirmam esta topologia.

Tabela da aula; deslize para ver todas as colunas →

Um componente num caminho é exigido sob este modelo. Se um componente exigido está indisponível, o script prevê que a função está prejudicada. Se todo componente exigido está marcado como disponível, prevê apenas possibilidade estrutural, não correção verificada. O modelo não implementa autenticação, persistência de dados, validade de cache, integridade da cópia, notificação de frequentadores nem desempenho.

Essas limitações não são fraquezas a ocultar. Definem qual pergunta de engenharia o modelo responde. Um modelo pequeno e explícito pode ajudar a identificar o próximo dono ou teste, desde que ninguém promova as previsões dele a observações reais.

Em contraste, o contrato de fonte de D1 pergunta se uma auditoria da aplicação ou um registro de identidade poderia provar o que de fato aconteceu. O exercício de regra de negócio do BSL1 confere sobreposições e semântica de cancelamento usando registros inventados e separados de reserva. PATH1 não faz nenhuma das duas coisas. Pergunta quais funções poderiam perder os pré-requisitos modelados sob perda de componente.

Uma falha de um único componente pode prejudicar várias funções diferentes

Considere o caso hipotético independente em que a base de dados do PATH1 fica indisponível. Como room_view, staff_edit e new_backup_job a listam como exigida, o modelo prevê que essas três funções estão prejudicadas. A página informativa e a recepção manual da central não a listam, portanto permanecem estruturalmente possíveis neste desenho simplificado.

Essa previsão não equivale a “o site está saudável”. Um morador pode alcançar uma página e falhar em ver uma lista confiável de salas. Também não equivale a “a biblioteca inteira não pode ajudar ninguém”. Sob a premissa fictícia de alternativa, a central ainda pode receber um pedido não confirmado.

Uma falha do serviço de identidade tem outra forma. Prejudica o caminho modelado de edição pela equipe, mas não prejudica necessariamente a visão de salas. Isto não estabelece que a Harbor Library de fato permite leitura sem autenticação; reflete só a peça independente.

Uma falha da central pode remover a alternativa manual enquanto os caminhos mediados pelo site permanecem estruturalmente possíveis. Na operação ordinária isto pode ser inconveniente; durante uma interrupção mais ampla pode remover o único caminho permitido para receber pedidos novos. Assim, a importância de negócio de uma dependência depende do contexto operacional.

A pergunta correta de incidente não é simplesmente “qual componente está vermelho?”. É qual função útil está afetada, que outro caminho permanece, e que promessa legítima ainda pode ser feita? Contagens de componentes não substituem essa análise.

Pontos únicos de falha precisam nomear o resultado afetado

Chamar um componente de “ponto único de falha” é incompleto sem nomear a função que ele pode impedir. No PATH1, a falha só de web impede a página informativa, a visão de salas e a rota de edição pela equipe. Não impede, sob a peça declarada, a recepção de pedidos na central nem um trabalho novo de cópia.

Do mesmo modo, a base de dados é um elemento exigido único para a visão modelada de salas, mas não para a página informativa. Uma aplicação real pode ter dependências adicionais ou uma rota alternativa que funcione; a tabela PATH1 não fornece evidência sobre elas.

Para uma função com dependências todas exigidas, a falha de qualquer componente listado basta para prejudicar aquele caminho modelado particular. Um desenho resiliente real poderia, em vez disso, ter alternativas — como duas instâncias equivalentes de serviço ou uma leitura em cache controlada. Tais alternativas precisam ser documentadas e testadas de forma explícita antes de serem usadas em decisões operacionais.

Este modelo inicial evita de propósito estimativas de probabilidade. Uma lista de componentes não fornece taxas de falha, correlações, tempos de reparo nem evidência de que capacidade alternativa é utilizável. Atribuir uma probabilidade inventada de indisponibilidade acrescentaria precisão sem suporte.

O valor de preparação deste raciocínio é pedir a um responsável pelo serviço que identifique o que é de fato essencial e qual rota alternativa pode atender com segurança a um requisito mais estreito. Não autoriza mudar uma configuração de produção.

Disponível, degradado, indisponível e desconhecido são conclusões diferentes

Uma rota pode estar modelada como disponível, modelada como prejudicada, observada a funcionar num teste limitado, ou ainda não testada. Essas afirmações não devem ser colapsadas num único rótulo verde/vermelho.

Para PATH1, a peça Python fornecida usa disponibilidade booleana de componente e prevê estado estrutural. Componentes reais podem falhar em parte: uma base pode responder leituras e rejeitar escritas; um serviço de identidade pode validar sessões antigas e não sessões novas; um cache pode devolver conteúdo obsoleto. Nessas circunstâncias um booleano simples pode esconder incerteza importante.

Se um analista não consegue determinar o estado real de um componente, seria impróprio entrar True só para o modelo devolver um resultado verde. Registre a condição como desconhecida e pergunte qual observação poderia resolvê-la. O script de sala omite um terceiro estado por simplicidade; quem estuda precisa relatar isso como limitação do modelo.

Uma resposta bem-sucedida de um ponto de extremidade web também não prova que uma mudança de reserva foi autorizada e confirmada de forma durável. Um recibo da central não prova que existe uma atribuição de sala. São exemplos de alegação excessiva a partir de sucesso parcial.

Um relatório preciso pode dizer: “sob o modelo selecionado, o caminho da página informativa permanece estruturalmente possível, enquanto o caminho de escrita de reserva está previsto como indisponível”. Não deve alegar que frequentadores reais podem usar o serviço com segurança sem um teste correspondente e aceitação do responsável.

Desenhe um modo degradado com limites explícitos

Um modo degradado não é simplesmente “o que ainda funciona”. Deve ser definido de antemão pelo responsável pelo serviço, com condições de ativação, um fluxo aprovado, uma duração ou gatilho de revisão, uma mensagem que descreva com exatidão os limites do serviço, e um caminho de volta à operação normal.

Para um modo hipotético de central só de pedidos, o responsável precisaria responder:

1. A equipe pode receber pedidos enquanto o serviço autoritativo de reserva está indisponível?
2. Quais detalhes mínimos podem ser coletados com segurança e para qual propósito?
3. O pedido permanece pendente até uma verificação autorizada posterior?
4. Quem mantém a ordem dos recibos e impede duplicatas ou instruções conflitantes?
5. Quem comunica aos frequentadores a distinção entre recebimento e aceitação?
6. Qual é a rota de escalada se a mesa não consegue acompanhar ou se o pedido é urgente?
7. Quem autoriza a reconciliação eventual e confirma o estado de negócio resultante?
8. Que resultado observável encerra o modo degradado?

Isto é um contrato de negócio proposto, não uma alegação de que a central canônica da Harbor Library seguiu tal procedimento. O laboratório MQ3 do módulo 3 da edição inglesa, ausente deste arquivo, ensina reconciliação detalhada de pedidos, mas PATH1 faz uma pergunta anterior e diferente: Aquele tipo de função alternativa permaneceria tecnicamente possível sob uma falha especificada de componente?

A recepção manual pode estar indisponível por política mesmo quando a central está funcionando. A equipe pode não ter capacidade, procedimentos aprovados em papel ou salvaguardas de privacidade. A possibilidade técnica de um modelo nunca se sobrepõe às restrições operacionais do responsável pelo serviço.

Uma frase segura de modo degradado diz “o pedido pode ser registrado para revisão”. Uma frase perigosa diz “a sala está reservada” quando a reserva aceita não foi estabelecida.

A prontidão precisa de um plano de verificação para cada função

Antes de aceitar a tabela de funções, um responsável pelo serviço e um custodiante técnico devem identificar o teste que a contestaria. Um plano útil de teste inclui:

• A função e o resultado prometido.
• Os componentes exigidos propostos.
• A falha isolada específica ou o componente indisponível.
• A previsão de prejuízo ou o comportamento alternativo.
• A observação técnica positiva a procurar.
• Uma verificação negativa ou de segurança de negócio.
• O dono responsável e o ambiente permitido.
• Uma fonte e um carimbo de tempo para o resultado real.
• O limite da conclusão e a revisão exigida.

Para a visão modelada de salas, uma resposta técnica sozinha pode ser insuficiente se devolve dados obsoletos ou não autorizados. Para edição pela equipe, um pedido bem-sucedido não prova que o valor autoritativo pretendido foi confirmado. Para um trabalho de cópia, a criação não prova que o objeto é recuperável. Para a recepção na central, um recibo não prova que o pedido foi aceito.

Este plano deve ser comparado com os artefatos existentes D1 e BSL1 sem copiar o conteúdo deles. D1 especifica como um registro poderia ser obtido e interpretado; BSL1 define algum comportamento correto de estado de reserva; PATH1 especifica quais pré-requisitos de caminho estão sendo contestados. Um teste isolado real pode recorrer aos três, mas as conclusões permanecem separadas.

Se o teste negativo esperado falha, registre a falha em vez de enfraquecer em silêncio a regra de aceitação. Se os dados de entrada estão incompletos ou a falha suposta não foi de fato induzida, relate um teste inconclusivo em vez de uma aprovação limpa.

Contraste uma conclusão tentadora e errada com uma defensável

Análise hipotética incorreta:

“A base está fora, mas a página inicial responde, portanto o serviço está saudável. A equipe pode receber pedidos na mesa, o que significa que as reservas ainda estão confirmadas. O componente de cópia permanece no ar, portanto a biblioteca já pode restaurar tudo.”

Isto assume que a página informativa representa todas as funções de reserva; que um pedido manual pendente é uma reserva concluída; e que um componente de cópia ou o resultado de um trabalho prova recuperação testada. Nenhuma das alegações segue do modelo PATH1, e nenhuma interrupção de base aparece em R1–R8 canônicos.

Análise limitada correta:

“No modelo independente PATH1, a indisponibilidade da base prevê prejuízo dos caminhos de visão de salas, de edição pela equipe e de trabalho novo de cópia, enquanto a página informativa e a recepção de pedidos na central permanecem estruturalmente possíveis. A recepção manual não aceita reservas, e nenhum teste de recuperação é fornecido. São previsões de sensibilidade a partir de premissas declaradas, não observações do incidente da Harbor Library. O responsável pelo serviço precisaria aprovar qualquer promessa operacional degradada, e uma verificação autorizada separada seria necessária para estabelecer a função real e a correção de negócio.”

A melhoria não é simplesmente linguagem cautelosa. Identifica a unidade de serviço, a fonte da alegação e a evidência de aceitação que falta.

Compare cenários de falha sem transformá-los em eventos canônicos

Um ensaio offline útil muda uma condição modelada de cada vez e registra quais funções mudam de classificação. O estudante deve começar pela linha de base, simular uma falha da base, restaurar a linha de base e simular falha de identidade. O mesmo processo pode ser usado para falhas da central e da web.

Sem reiniciar o modelo, as conclusões podem se misturar: uma condição persistente de base indisponível pode fazer um teste de identidade parecer prejudicar mais funções do que realmente prejudica. O código abaixo evita isso ao avaliar conjuntos independentes de falha, em vez de alterar as definições compartilhadas de rota.

As comparações devem ser explicadas em termos de negócio. Se a falha de identidade afeta só o caminho de edição pela equipe, isso é diferente de uma falha da base afetar visão, edição e criação de cópia nova. Se a falha da central remove a recepção, o dano potencial depende em parte de os usuários terem outro meio aprovado de fazer pedidos.

Uma falha de dois componentes é útil como controle negativo. Com base e central indisponíveis sob PATH1, a página informativa restante não pode fornecer escritas de reserva aceitas nem receber pedidos pendentes. Seria enganoso rotular esse estado como “serviço de reserva parcialmente operacional” sem especificar a função limitada só de informação.

A peça não fornece frequência, probabilidade nem nota de severidade para esses cenários. Isso exige informação do responsável pelo serviço e evidência operacional medida fora da sala.

Relação com as decisões de incidente às 09:05

Volte ao conjunto real e fictício de fontes da Rodada A. R1 relata uma entrada de desk-a, R3 e R4 relatam mudanças de reserva, R5 é uma preocupação de frequentador, R6 descreve treinamento agendado, R7 relata a conclusão de um trabalho de cópia e R8 carece de detalhe suficiente de destino. Esses registros sustentam perguntas sobre aprovação, estado do serviço e contexto de identidade. Não estabelecem qualquer interrupção de componente PATH1.

Um estudante pode propor, com razão, que o responsável pelo serviço esclareça o que aconteceria se a base estivesse indisponível, ou se uma alternativa só de pedidos está aprovada. Essa é uma pergunta de prontidão, não um achado sobre o incidente.

Um cenário PATH1 nunca deve ser inserido como linha adicional da série R nem usado para justificar a decisão de restrição das 09:05. Do mesmo modo, os eventos posteriores B19/B20 ou os resultados dos ramos S/P, que pertencem a capítulos posteriores da edição inglesa, não podem ser importados para trás a fim de resolver a incerteza original.

Quem responde com qualidade pode manter dois livros: o livro de evidência canônica, limitado aos registros de caso liberados, e um livro de modelo e teste, contendo premissas declaradas e resultados hipotéticos. Essa separação permite planejamento tecnicamente útil sem ficcionalizar observações de produção.

Síntese da seção: resiliência é uma promessa limitada de serviço

Resiliência não é uma garantia de que todo componente permanece no ar. É a capacidade de definir resultados importantes para o usuário, identificar como a falha de um componente poderia afetá-los, preparar modos mais estreitos aceitáveis e testar o que esses modos de fato entregam.

Um site pode estar alcançável enquanto a visão atual de salas está prejudicada. Uma central pode conseguir receber um pedido sem confirmar uma reserva. Um trabalho de cópia pode ser possível sem demonstrar recuperação. Reconhecer essas distinções melhora a qualidade das perguntas de incidente e torna mais defensáveis as decisões posteriores do responsável pelo serviço.

O laboratório PATH1 é pequeno de propósito. Treina um hábito transferível: prever consequências estruturais, identificar a promessa de negócio e exigir observação adequada antes de declarar impacto ou recuperação de serviço.

Laboratório offline PATH1 — dependências funcionais e serviço degradado

Classificação: Exercício independente de modelagem, inteiramente sintético. Não é R1–R24, não é a peça de estado de reserva BSL1, não é a arquitetura de nível técnico L6 e não é uma interrupção registrada da Harbor Library.

Ambiente: biblioteca padrão do Python 3, em memória. Sem arquivos, chamadas de rede, credenciais reais ou modificações de serviço.

Tarefa de previsão: Antes de executar, preveja quais funções permanecem em cada cenário e se o resultado significa disponibilidade modelada de edição pela equipe, só recepção de pedidos, ou nenhuma rota modelada de edição pela equipe nem de recepção.

O modo de resumo classifica só os caminhos de edição pela equipe e de recepção de pedidos. Leia a lista separada available antes de dizer se a visão de salas ou qualquer outra função permanece possível.

Programa Python completo

ROUTES = {
    "site_reachable": {"web"},
    "room_view": {"web", "database"},
    "staff_edit": {"web", "identity", "database"},
    "manual_intake": {"helpdesk"},
    "new_backup_job": {"database", "backup"},
}

CASES = [
    ("BASE", set()),
    ("DATABASE_DOWN", {"database"}),
    ("IDENTITY_DOWN", {"identity"}),
    ("HELPDESK_DOWN", {"helpdesk"}),
    ("WEB_DOWN", {"web"}),
    ("DATABASE_AND_HELPDESK_DOWN", {"database", "helpdesk"}),
]

def assess_failed(failed):
    available = sorted(
        name for name, needs in ROUTES.items()
        if needs.isdisjoint(failed)
    )
    impaired = sorted(set(ROUTES) - set(available))

    if "staff_edit" in available:
        mode = "STAFF_EDIT_PATH_MODELED"
    elif "manual_intake" in available:
        mode = "NO_STAFF_EDIT_INTAKE_MODELED"
    else:
        mode = "NO_EDIT_OR_INTAKE_PATH"

    return available, impaired, mode

for name, failed in CASES:
    available, impaired, mode = assess_failed(failed)
    print(
        f"{name}: available={','.join(available)} "
        f"impaired={','.join(impaired)} mode={mode}"
    )

assert assess_failed({"database"})[2] == "NO_STAFF_EDIT_INTAKE_MODELED"
assert "room_view" not in assess_failed({"database"})[0]

Preveja as seis linhas de saída antes de rodar o programa e, em seguida, compare o resultado com a resolução PATH1 no apêndice final. Mantenha PATH1 separado da evidência de caso da série R.

Unidade de revisão da semana 1, número 3 — Rejeitar nomes desconhecidos; modelar estados desconhecidos

Objetivo e contraexemplo

Distinga um identificador inválido de componente de um componente válido com estado desconhecido. Em seguida, explique por que um pré-requisito falho e conhecido pode estabelecer prejuízo modelado mesmo quando outro pré-requisito está sem resolução.

O PATH1 original avalia um conjunto de componentes falhos. Se o conjunto fornecido é {"databsae"}, o nome com erro de grafia não intersecta nenhum dos cinco conjuntos de dependência de rota. A função original, em consequência, devolve toda função modelada como disponível. Esta é uma limitação reproduzível de fronteira de entrada, não um relatório de que uma base ou um serviço real estava saudável.

Uma guarda de identificador deve rejeitar essa grafia em vez de adivinhar que o autor pretendia database. Correção silenciosa poderia ocultar uma fonte errada, uma mudança de esquema ou um componente diferente. Peça uma entrada corrigida explícita e preserve a original.

Um problema diferente surge quando database está grafado corretamente, mas o estado não é conhecido. Rejeitar o nome seria errado; entrar False inventaria uma interrupção; entrar True inventaria disponibilidade. A extensão usa None para representar esta condição desconhecida definida de forma estreita, com todo componente explicitamente presente no dicionário de estado.

Raciocine por três estados

PATH1 define cada rota como um conjunto de todos exigidos. Sob esse modelo, uma função é:

Tabela da aula; deslize para ver todas as colunas →

Considere a edição pela equipe, que exige web, identidade e base. Com web e identidade verdadeiras e base desconhecida, a rota está sem resolução. Com web verdadeira, identidade falsa e base desconhecida, a rota está prejudicada qualquer que seja a resolução posterior da incerteza da base. O pré-requisito falho e conhecido é suficiente dentro deste modelo. Essa conclusão não identifica a causa de uma interrupção real, não quantifica dano nem estabelece que uma arquitetura alternativa está ausente.

A recepção manual depende só de helpdesk no PATH1. Se helpdesk é verdadeiro, essa rota pode permanecer possível enquanto a edição pela equipe está prejudicada. “Possível” ainda significa uma rota modelada, não uma reserva de sala confirmada, um procedimento alternativo aprovado ou entrega observada de serviço.

Extensão reproduzível do PATH1

Rode primeiro a listagem original completa do PATH1 numa sessão nova. Preveja manualmente as quatro primeiras linhas novas. O laço final confere todas as 3^5 = 243 atribuições parciais entre os cinco componentes. Para cada atribuição, enumera toda atribuição booleana completa consistente com os desconhecidos declarados e compara os resultados possíveis de cada função com a classificação de três estados.

Esta comparação é um cálculo independente sobre um modelo finito declarado. Não verifica topologia real, medições, permissões, caminhos alternativos nem correção do serviço. Para sistemas reais, as próprias premissas exigem observação autorizada e revisão do responsável.

# Run after the complete PATH1 listing, in the same Python session.
W1_COMPONENTS = frozenset().union(*ROUTES.values())

def w1_assess_failed(failed):
    if type(failed) not in (set, frozenset):
        raise ValueError("INVALID_FAILURE_SET")
    if not failed.issubset(W1_COMPONENTS):
        raise ValueError("UNKNOWN_COMPONENT")
    return assess_failed(failed)

def w1_assess_state(state):
    if type(state) is not dict or set(state) != set(W1_COMPONENTS):
        raise ValueError("COMPONENT_SET_MISMATCH")
    if any(value is not None and type(value) is not bool for value in state.values()):
        raise ValueError("INVALID_COMPONENT_STATE")
    result = {}
    for function, needs in sorted(ROUTES.items()):
        values = [state[component] for component in needs]
        if any(value is False for value in values):
            result[function] = "IMPAIRED"
        elif any(value is None for value in values):
            result[function] = "UNRESOLVED"
        else:
            result[function] = "POSSIBLE"
    return result

try:
    w1_assess_failed({"databsae"})
except ValueError as error:
    print("W1_TYPO", str(error))
w1_state = {component: True for component in W1_COMPONENTS}
w1_state["database"] = None
print("W1_UNKNOWN_DB", w1_assess_state(w1_state)["staff_edit"])
w1_state["identity"] = False
print("W1_UNKNOWN_DB_IDENTITY_DOWN", w1_assess_state(w1_state)["staff_edit"])
print("W1_MANUAL", w1_assess_state(w1_state)["manual_intake"])

# Independent finite check: compare each partial assignment with every
# complete Boolean assignment consistent with it. No real system is queried.
from itertools import product
w1_names = sorted(W1_COMPONENTS)
w1_checked = 0
for values in product((False, True, None), repeat=len(w1_names)):
    partial = dict(zip(w1_names, values))
    unknown = [name for name in w1_names if partial[name] is None]
    completions = []
    for fill in product((False, True), repeat=len(unknown)):
        complete = {**partial, **dict(zip(unknown, fill))}
        completions.append(complete)
    actual = w1_assess_state(partial)
    for function, needs in ROUTES.items():
        outcomes = {all(complete[name] is True for name in needs) for complete in completions}
        expected = ("POSSIBLE" if outcomes == {True} else
                    "IMPAIRED" if outcomes == {False} else "UNRESOLVED")
        if actual[function] != expected:
            raise AssertionError((partial, function, actual[function], expected))
    w1_checked += 1
print("W1_PARTIAL_STATES_CHECKED", w1_checked)

Prática suplementar W1-R3

Objetivo: justificar um resultado sob conhecimento incompleto de componentes. Entradas: as cinco funções PATH1, as dependências originais e a extensão acima. Artefato exigido: a transcrição de cinco linhas; uma tabela das cinco funções com a base desconhecida e todos os outros componentes verdadeiros; uma segunda tabela depois de só a identidade se tornar falsa; e uma mensagem de duas frases ao responsável pelo serviço, distinguindo recepção modelada de aceitação confirmada de reserva. Restrições: não transforme desconhecido em falso, não repare o erro de grafia em silêncio e não importe qualquer falha modelada para R1–R8.

Avaliação: um ponto para cada um: rejeição do erro de grafia, a primeira tabela completa de funções, a segunda tabela completa, a mensagem limitada ao responsável pelo serviço, e a explicação do que a enumeração finita não verifica. O EX003 original ainda exige os dois cartões de dependência; esta tabela é prática suplementar separada. Resolução.

Rubrica: 3 = cinco pontos da fonte: rejeição do erro de grafia, duas tabelas completas, mensagem limitada e o que a enumeração de 243 não verifica;; 2 = a maior parte desses pontos, com uma omissão de limite;; 1 = responde, mas omite fonte, limite ou trata estado desconhecido como falha;; 0 = nenhum.

Síntese da revisão

Um nome inválido é um defeito de entrada. Um estado desconhecido é uma premissa sem resolução. Um pré-requisito falho e conhecido pode resolver uma rota modelada sem resolver toda outra incerteza.

Marco resolvido

Se a aplicação de reservas responde, mas o estado autoritativo da reserva é desconhecido, disponibilidade não é correção de negócio. Um caminho de recepção manual pode preservar uma promessa limitada ao usuário, mas não pode ser chamado de aceitação confirmada de reserva sem reconciliação aprovada pelo responsável.

Prática — Aula 03

EX003 — Dependência de serviço

Objetivo: ligar um sinal de incidente a resultados de serviço e a donos de evidência. Entradas: o mapa de serviço da seção 1.2 e R1–R8. Saída: um cartão de dependência de duas linhas com dependência, dano possível ao usuário, ponteiro fornecido, evidência discriminante ausente e custodiante. Escolha duas dependências; para cada uma, explique o que uma verificação autorizada distinguiria. Não chame um dano potencial de interrupção confirmada. Uma nota 2 precisa de duas dependências diferentes e de um teste que possa separar um problema de estado de serviço de uso indevido de conta.

Extensão: Para cada uma das duas dependências de serviço escolhidas, distinga um dano possível de negócio a jusante de uma observação real. Nomeie um teste negativo que poderia enfraquecer a explicação proposta e identifique quem estaria autorizado a pedi-lo.

Para crédito completo: Uma resposta de 2 pontos liga explicitamente fontes técnicas diferentes a decisões diferentes. Os valores atuais de reserva da base não podem ser inferidos diretamente do histórico de edição de R3–R4.

Tarefa suplementar PATH1 (depois do artefato exigido):

Requisito adicional: Depois dos dois cartões de dependência existentes, escolha uma função modelada PATH1 e identifique uma falha de componente que a prejudicaria. Declare uma verificação autorizada funcional e uma verificação separada de correção de negócio. Não alegue que a falha PATH1 ocorreu em R1–R8 canônicos.

Resolução: EX003 no apêndice final.

Rubrica: 3 = nota 2 da fonte: duas dependências diferentes, um teste que separa estado de serviço de uso indevido de conta, e a tarefa PATH1 sem importar a falha para R1–R8;; 2 = os dois cartões existem, mas falta o teste que separa as explicações;; 1 = responde à pergunta, mas omite fonte, limite, autoridade ou trata dano possível como interrupção confirmada;; 0 = nenhum.

EX008 — Qualidade da evidência

Objetivo: limitar alegações ao que três tipos diferentes de fonte de fato dizem. Entradas: R6–R8. Saída: uma tabela de limite de evidência com três linhas, com identificador e hora, conclusão estreita sustentada, conclusão tentadora sem suporte, e uma fonte ou teste de acompanhamento. Uma nota 2 trata uma atividade agendada como distinta de uma mudança de reserva aprovada, um trabalho de cópia concluído como distinto de uma restauração provada, e um resumo sem detalhe de destino como distinto de uma ausência verificada de transferência.

Tarefa suplementar PATH1 (depois do artefato exigido):

Requisito adicional: Na linha de estado de cópia de R7, explique por que a disponibilidade modelada de new_backup_job não verificaria restauração utilizável, recuperação decorrida aceitável nem correção de reserva aprovada pelo responsável. Preserve as limitações originais de fonte do treinamento em R6 e do resumo de rede em R8.

Resolução: EX008 no apêndice final.

Rubrica: 3 = nota 2 da fonte: três linhas que separam agenda de aprovação, trabalho de cópia de restauração provada, e resumo sem destino de ausência de transferência;; 2 = as três linhas existem, mas uma conclusão sem suporte é tratada como sustentada;; 1 = responde à pergunta, mas omite fonte, limite ou o teste de acompanhamento;; 0 = nenhum.

EX011 — Gatilho de escalada

Objetivo: especificar quando a escolha inicial precisa ser reaberta. Entradas: o instantâneo R1–R8 e a seção 1.9. Saída: duas linhas hipotéticas de observação e resposta, com a fonte que verificaria o sinal, o dano ou a incerteza afetada, o dono da decisão e a próxima ação. Um gatilho deve tratar de mudança contínua de reserva; o outro deve tratar de amplitude ou impacto no serviço. Uma nota 2 afirma que nenhuma das observações está presente às 09:05 e evita uma ação automática de produção sem aprovação.

Extensão de linha de base de comportamento: Para o gatilho hipotético de impacto no serviço, especifique uma comparação futura, aprovada pelo responsável, do estado de reserva contra a versão aplicável da política, com o responsável pelo serviço confirmando regra e escopo. Mantenha o outro gatilho sobre uma edição nova, inexplicada e verificada à parte. Nenhum dos sinais está presente em R1–R8; um descompasso de regra não prova comprometimento cibernético.

Resolução: EX011 no apêndice final.

Rubrica: 3 = nota 2 da fonte: dois gatilhos hipotéticos, nenhum presente às 09:05, sem ação automática de produção, e descompasso de regra distinto de comprometimento;; 2 = os dois gatilhos existem, mas um é tratado como observação já presente;; 1 = responde à pergunta, mas omite fonte, limite, autoridade ou aprovação;; 0 = nenhum.